Sistemas de Gestión de Bases de Datos

7.2.1 Oracle

Oracle [8] ofrece un completo paquete de herramientas y aplicaciones para desarrollar, desplegar, gestionar y poner a punto aplicaciones que requieran una alta disponibilidad. Una discusión completa de estas herramientas se extendería durante varios capítulos, por este motivo, esta sección se centra únicamente en explicar algunas de las características de alta disponibilidad ofrecidas:

Clústeres reales de aplicaciones Oracle.o Alta disponibilidad usando clústeres reales de

aplicaciones.o Ventajas de los clústeres reales de aplicaciones.o Desventajas de los clústeres reales de aplicaciones.

Recuperación transparente de fallos de aplicación.o Alta disponibilidad usando la recuperación

transparente de fallos de aplicación.o Ventajas de la recuperación transparente de fallos

de aplicación.o Desventajas de la recuperación transparente de

fallos de aplicación. Oracle Data Guard

o Alta disponibilidad usando Oracle Data Guard.o Ventajas de Oracle Data Guard.o Desventajas de Oracle Data Guard.

Replicación Avanzada.o Alta disponibilidad usando replicación avanzada.o Ventajas de la replicación avanzada.o Desventajas de la replicación avanzada.

Combinación de múltiples soluciones.

7.2.1.1 Clústeres reales de aplicaciones Oracle

Oracle RAC (Oracle Real Application Clusters) [8] es una configuración de base de datos que consiste en múltiples instancias de la base de datos con acceso compartido al mismo conjunto de archivos de datos. Como su predecesor, RAC está configurado en combinaciones de hardware/SO específicas capaces de soportar un entorno de clúster.

El Oracle RAC es una combinación de un número de distintos componentes hardware y software. La lista siguiente detalla los componentes individuales y sus funciones:

Hardware del servidor clúster: El hardware físico en el que se aloja la base de datos RAC. Esto comprende dos o más nodos uniprocesador o multiprocesador conectados en una configuración clúster con una interconexión de alta velocidad para la comunicación entre nodos.

Discos compartidos del clúster: Los discos compartidos en los que se almacenan los archivos de la base de datos. Los discos compartidos deben permitir accesos directos al disco simultáneos desde todos los nodos del clúster. Las configuraciones de discos compartidos pueden ser SAN (Store Area Network), RAID compartidos o NAS (Network Attached Storage), pudiendo conectarse tanto directamente a los nodos del clúster como a una interconexión de alta velocidad.

Gestor del clúster: Las funciones OSD (Operating System Dependent) para el control de la funcionalidad del clúster. Esto se compone de dos módulos distintos. Primero, el demonio Global Services ejecuta tareas en nombre del software RAC, como el cierre, inicio y otras acciones de tipo administrativo en los nodos individuales del clúster. Segundo, el Node Monitor es responsable de mantener la comunicación entre los nodos del clúster y el software RAC. Esto incluye supervisión del estado de los nodos del clúster y el paso de esta información al software RAC.

Servicio global de cahé/colas: Controla el acceso a los recursos de todos los nodos que forman parte del RAC. Durante las operaciones de bases de datos en las que debe accederse al mismo recurso desde múltiples sesiones, el servicio Global Cache/Enqueue se encarga de coordinar las operaciones entre los nodos del clúster. Operaciones como el acceso a bloques de datos en caché o la ejecución de operaciones de bloqueo, deben producirse de forma transparente independientemente de la sesión a la que esté asociado el nodo. Se utiliza un esquema conocido como dominio de recurso para permitir que la propiedad de un recurso ``flote'' entre los nodos, dependiendo de dónde sea óptimamente referenciado.

Fusión de caché: Una de las capacidades más poderosas de RAC. Utilizando los servicios globales de caché y colas, la fusión de cachés permite que las sesiones conectadas a un nodo del clúster hagan referencia a bloques de bases de datos que están en la memoria caché de un nodo distinto. Cuando se solicita la lectura de un bloque de base de datos, si el bloque de datos referenciado ya está en la caché de uno de los nodos del clúster, Oracle usa la interconexión de alta velocidad para copiar el bloque entre los nodos. Cuando se solicita la escritura de un bloque en la base de datos, si el bloque ya está en la caché de uno de los otros nodos del clúster, Oracle de nuevo copia los datos entre los nodos pero ahora la propiedad se asigna al nodo que está ejecutando la actualización del bloque de datos. Las operaciones de lectura adicionales sobre el bloque pueden continuar en otros nodos, pero cualquier escritura del bloque en base de datos se verá forzada a esperar hasta que la primera sesión que está actualizando efectúe una confirmación (commit) o un rechazo (rollback).

Siempre que se produce un fallo en uno de los nodos del clúster, se ponen en marcha las siguientes operaciones:

El demonio de Global Services efectúa una reorganización del clúster que implica determinar qué nodos ya no forman parte del clúster. Esto se logra indicando a cada instancia de base de datos que actualice su entrada en el mapa de miembros contenido en el archivo de control. Al final del proceso, las entradas sin actualizar del mapa de pertenencia se juzgan como nodos con fallos.

La recuperación de la base de datos implica determinar qué bloques de caché y bloqueos de objetos de la base de datos pertenecen a la instancia que ha fallado. Asimismo, es necesario reasignar la propiedad de los recursos.

La recuperación de transacción conlleva la lectura de los archivos de registro para rehacer el nodo que ha fallado, para determinar las transacciones que deben aplicarse y las transacciones incompletas que deberían ser deshechas. Dependiendo de la cantidad de recuperación que deba efectuarse, este proceso puede

tomar una cantidad de tiempo excesivo. La característica fast-start-rollback le permite ajustar la duración máxima del proceso de recuperación y facilita que la recuperación se efectúe en paralelo.

Las dos configuraciones de alta disponibilidad más simples que se pueden crear utilizando RAC usan un clúster de dos nodos con una configuración primario/secundario. Este método usa una base de datos primaria activa que da servicio a la mayoría de las solicitudes de conexión de la aplicación. La base de datos secundaria normalmente no responde a las solicitudes de la aplicación, aunque con la configuración de red apropiada, la instancia secundaria puede conectarse directamente para operaciones como el mantenimiento o los informes por lotes. En caso de fallo de la instancia primaria, la secundaria toma el control efectuando la devolución de transacción y recuperación de instancia. Todos los intentos de conexión siguientes son entonces dirigidos a la instancia secundaria. Los dos tipos de configuración RAC primaria/secundaria son:

Oyente dedicado básico de clúster real de aplicación es una configuración en la que cada base de datos tiene su propio oyente. La aplicación se configura para conectar con el oyente de la primera base de datos. Cuando una solicitud de conexión no puede ser satisfecha por la primera base de datos, la aplicación conecta con la segunda base de datos. En ese caso, todas las transacciones que se encontraban en curso son canceladas. La figura 7.1 muestra la configuración de oyentes para la configuración de oyente dedicado básico RAC.

Figura 7.1: Oyente dedicado básico RAC

Oyente compartido básico de clúster real de aplicación. Una configuración en la que las bases de datos comparten uno o más oyentes. Cuando se inicia la base de datos primaria, se registra con cada uno de los oyentes. La aplicación entonces se configura para conectar con cualquiera de los oyentes y las solicitudes son enviadas a la instancia primaria. Cuando la instancia primaria falla, la instancia secundaria efectúa la recuperación, se registra como instancia primaria y acepta todas las conexiones siguientes. Cualquier transacción que estuviese en proceso cuando falló la instancia primaria es cancelada y la aplicación tiene que reconectar. La figura 7.2 muestra la configuración de oyentes para la configuración oyente compartido básico RAC.

Figura 7.2: Oyente compartido básico RAC

Ventajas de los clústeres reales de aplicaciones

Los RAC (Real Application Clusters) ofrecen las siguientes ventajas:

Son mínimos los cambios requeridos en la aplicación para aprovechar las características ofrecidas por la arquitectura del RAC.

Crear una solución de alta disponibilidad es extremadamente fácil usando el RAC de dos nodos.

En una configuración primario/secundario, la recuperación de instancias tras el fallo de un nodo es automática, mejorando así el tiempo medio de recuperación o MTTR (mean time to recover).

Combinando el RAC con otras características, como Oracle RAC Guard, recuperación transparente de fallos de aplicación y Oracle Data Guard se puede crear una arquitectura extremadamente potente, altamente escalable así como flexible.

Desventajas de los clústeres reales de aplicaciones

Los RAC Real Application Clusters) tienen las desventajas que se exponen a continuación:

Al compartir el subsistema de disco todos los nodos participantes, la configuración es todavía débil a los fallos de disco a menos que se den pasos específicos para prevenirlos. Estos pasos incluyen espejos por hardware.

Dado que la interconexión de alta velocidad es el punto central de comunicación entre los nodos del clúster, a menos que se use redundancia puede convertirse en un punto de posibles fallos.

RAC puede proteger tan sólo contra fallos localizados en caídas de los nodos del clúster. Por sí mismo, no ofrece ninguna redundancia remota como la que es necesaria para prevenir desastres como la pérdida completa de un centro de datos.

Pueden conseguirse mejoras adicionales de alta disponibilidad y escalabilidad combinando RAC con otras posibilidades de Oracle.

7.2.1.2 Recuperación transparente de fallos de aplicación

Una de las consideraciones de diseño más importantes de cualquier aplicación es la transparencia para el usuario final que nunca debería conocer la arquitectura de la aplicación. Desde la perspectiva del usuario, las interrupciones frecuentes del servicio pueden resultar frustrantes. Incluso la más elegante solución de alta disponibilidad puede parecer molesta a los usuarios si requiere que tengan que reconectar y reiniciar su trabajo.

TAF (Transparent Application Failover) [8] es un componente de Oracle Networking que puede utilizarse para minimizar la interrupción causada por temas relacionados con conectividad. Cuando se pierde la conexión entre la aplicación y la base de datos, TAF ejecuta las siguientes funciones dependiendo de como haya sido configurado:

Restauración de sesiones de base de datos: Se restaura la conexión a la base de datos usando el mismo identificador de usuario y clave utilizados previamente.

Continuación de operaciones SELECT: Las sentencias SELECT emitidas previamente vuelven a ejecutarse, continuando a partir del mismo punto en que se produjo la desconexión.

Puesto que TAF no restaura transacciones dudosas, las variables de sesión de usuario perderán su estado tras la recuperación del fallo. Si se requiere transparencia completa en la aplicación, sin embargo, puede combinarse una composición de funciones de retorno para recuperación de fallos con la escritura de valores en una tabla temporal en la base de datos para restauración tras la recuperación del fallo.

A pesar de no ser estrictamente una característica de TAF, un componente adicional de Oracle Networking que puede utilizarse para múltiples instancias de bases de datos, como con RAC, para mejorar la transparencia de la aplicación, es el balanceo de cargas. Esto permite que las conexiones a la aplicación se repartan entre todas las instancias de bases de datos disponibles. El balanceo de cargas puede usarse también con bases de datos replicadas y bases de datos de reserva de Oracle Data Guard. Cuando se combina con la reconexión automática de TAF, esto ofrece una mejora significativa de alta disponibilidad minimizando la interrupción de sesiones. 

Ventajas de la recuperación transparente de fallos de aplicación

TAF ofrece las siguientes ventajas:

Las aplicaciones pueden reconectarse transparentemente a la base de datos sin intervención del usuario.

Las sentencias SELECT previamente ejecutadas continúan donde se quedaron.

TAF puede combinarse con el balanceo de cargas para mejorar la escalabilidad y disponibilidad de forma significativa.

Desventajas de la recuperación transparente de fallos de aplicación

TAF tiene las siguientes desventajas:

No es posible la restauración de toda la información de sesión.

Las transacciones previas son deshechas.

7.2.1.3 Oracle Data Guard

ODG (Oracle Data Guard) [8] ofrece una solución integrada para la configuración y gestión de bases de datos de reserva. Una implementación de base de datos de reserva consiste en una o más bases de datos que son copias separadas de una base de datos en producción. A diferencia de las bases de datos RAC, las bases de datos de reserva pueden situarse en la misma localización dentro del mismo centro de datos que la base de datos en producción, localizarse remotamente en una red de área ancha (WAN) o una combinación de ambos. Algunos de los usos de las bases de datos de reserva incluye el mantenimiento de bases de datos separadas para informes, una base de datos fuera de sede para recuperación de desastres o una copia de la base de datos de producción usada para desarrollo o prueba de aseguramiento de la calidad.

La lista siguiente incluye algunos de los muchos componentes que son parte de la arquitectura ODG.

Base de datos primaria: La base de datos en producción que es la fuente de datos para la instancia de reserva. Una sola base de datos primaria puede tener múltiples bases de datos de reserva.

Base de datos de reserva: La base de datos que es copia de la base de datos primaria en producción.

Servicios de registro: El método por el que los registros de rehacer son transferidos desde la base de datos primaria a las bases de datos de reserva. También controlan la frecuencia con que los archivos de registro para rehacer se aplican a las bases de datos de reserva.

Data Guard Broker: Es el componente software que se encarga de la creación, control y gestión de la configuración de base de datos primaria/secundaria.

Sede de Data Guard: La colección de una base de datos primaria y hasta nueve bases de datos de reserva.

Una base de datos de reserva puede crearse utilizando tanto el componente Data Guard Manager de Oracle Enterprise

Manager como herramientas desde la línea de comandos. Crear y gestionar una sede ODB implica estos pasos:

Configurar la base de datos primaria: La base de datos primaria debe estar funcionando en modo ARCHIVELOG y la misma plataforma hardware, versión de SO y versión del software RDBMS que el usado para la base de datos de reserva.

Determinación del modo de protección. Cuando cree una base de datos de reserva, considerar qué modo de protección es el apropiado, podría ser importante. ODG permite utilizar un número de distintos modos de protección.

o Modo de protección garantizada: Asegura que todos los cambios sean propagados a la sede de la base de datos de reserva después de que hayan sido confirmados en la base de datos primaria.

o Modo de protección instantánea: Asegura que todos los cambios se propaguen a la base de datos de reserva tras ser confirmados en la base de datos primaria a menos que la conectividad de la red lo impida. Una vez que la conectividad de red se haya restablecido, los registros para rehacer se aplican para conseguir que la base de datos de reserva esté actualizada.

o Modo de protección rápida: Procura que los cambios se propaguen a la base de datos de reserva tan pronto como sea posible, sin causar una degradación del rendimiento en la base de datos primaria.

o Modo de protección demorada: Asegura la propagación de todos los cambios a la base de datos de reserva una vez ha transcurrido un pequeño periodo de tiempo. Con la espera del modo de protección demorado, el retraso en la propagación puede especificarse para permitir que la base de datos quede detrás de la base de datos en producción.

Determinar el modo de operación de reserva: Utilizado para controlar la frecuencia con que los cambios se aplican a la base de datos de reserva tras la propagación desde la base de datos primaria. La base de datos puede estar funcionando en uno de los dos modos siguientes:

o Modo de recuperación gestionada: Permite a la base de datos de reserva aplicar todos los cambios tan pronto como se propaguen a la sede de reserva. La base de datos no está disponible para uso, sin embargo, hasta que ha sido abierta.

o Modo de sólo lectura: Permite que la base de datos permanezca abierta sólo para consultas de sólo lectura. Sin embargo, no se aplican cambios a la base de datos hasta que el modo se cambia a modo de recuperación gestionada.

La figura 7.3 muestra de forma global la arquitectura de ODG.

Figura 7.3: Arquitectura de Oracle Data Guard

Una vez se han creado y configurado las bases de datos de reserva, el broker ODG gestiona y supervisa la propagación y aplicación de registros para rehacer, dependiendo del modo de protección seleccionado. Ya que ODG permite la creación de múltiples instancias de reserva, la mejor configuración de protección podría ser tener un número de bases de datos de reserva, cada una de ellas con un modo de protección distinto.

Si la base de datos primaria queda innaccesible por problemas de hardware en el nodo de la base de datos primaria, puede iniciarse una recuperación del fallo con la base de datos de reserva. La cantidad de datos perdidos durante la operación de recuperación del fallo dependerá del modo de protección elegido. Una vez se haya producido la

recuperación del fallo, la base de datos de reserva asume el papel de base de datos primaria.

Una vez resuelto el problema de hardware en el nodo de la base de datos primaria, volver a la configuración original requiere volver a crear una instancia de la base de datos copiando de nuevo la base de datos y reconfigurando el nodo de reserva con su estado original.

ODG permite el inicio manual de un intercambio desde la base de datos primaria a la base de datos de reserva sin necesidad de reinstanciar cuando se produzca la vuelta a la situación original. Esto puede ser útil para efectuar mantenimiento en los nodos de bases de datos. 

Ventajas de Oracle Data Guard

ODG ofrece las siguientes ventajas:

Puede ser utilizado conjuntamente con RAC y la recuperación transparente de fallos de aplicación.

Dependiendo del modelo de protección elegido, el intercambio y recuperación de errores puede ocurrir con poca o ninguna pérdida de información.

La configuración y administración se simplifican con Data Guard Manager.

Data Guard ofrece recuperación de desastres si la base de datos de reserva se mantiene en una localización remota.

Data Guard es flexible puesto que la base de datos de reserva puede mantenerse automáticamente o de forma manual mediante entradas de usuario y/o guiones.

Las necesidades de ancho de banda son menos intensivas comparadas con otras soluciones de alta disponibilidad ya que sólo se propagan los archivos de registro guardados desde la base primaria a la que está en reserva.

Desventajas de Oracle Data Guard

ODG tiene las siguientes desventajas:

Aunque ODG puede configurarse para funcionar en nodos locales, no ofrece la misma escalabilidad que los Oracle RAC.

Dependiendo del modo de protección elegido, el intercambio y recuperación ante fallos pueden necesitar una cantidad de tiempo significativa.

La frecuencia de la propagación depende mucho del ancho de banda disponible en la red. En un entorno con un significativo volumen de cambios en la base de datos, la cantidad de cambios propagados puede provocar un excesivo tráfico en la red.

No existe un mecanismo fácil de vuelta atrás para volver a la máquina primaria original una vez que se ha activado la de reserva. La base de datos de reserva debe reconstruirse como si fuera la primaria e iniciarse una recuperación de fallo en la primaria original (ahora la de reserva).

Mientras la base de datos de reserva está abierta en modo sólo de lectura, no puede mantenerse sincronizada con la base de datos primaria (esto es, no pueden aplicarse los archivos de reconstrucción guardados mientras está abierta).

Los datos no presentes en los registros de reconstrucción guardados (como las tablas e índices creados mediante la opción NOLOGGING/UNRECOVERABLE) no se propagan a la reserva. Por ello, los comandos que desconectan la reconstrucción deben evitarse o tienen que implementarse medidas explícitas para registrar y propagar manualmente esos comandos. La implementación de un procedimiento robusto de parcheo de base de datos puede ayudar a través de los registros de reconstrucción archivados si no se detecta y rectifica a tiempo.

La base de datos de reserva debe estar funcionando en el mismo hardware, versión de SO y versión de DBMS que la base de datos principal.

7.2.1.4 Replicación avanzada

AR (Advanced Replication) [8] es un sofisticado mecanismo de replicación disponible en Oracle. AR permite que una o más bases de datos origen, con ciertos esquemas predeterminados, e incluso con segmentos específicos dentro de cada base de datos sean replicadas a una o más bases de datos destino en un esquema de replicación de sentido único o múltiple. Así, tanto las base de datos de origen como las de destino pueden gestionar de forma concurrente las lecturas y

escrituras. Desde una perspectiva lógica, AR ofrece una base de datos de reserva ``en caliente''.

A diferencia de un escenario convencional de base de datos de reserva, la base de datos destino está abierta y disponible para recuperación inmediata ante un fallo de la base de datos origen (ver figura 7.4). Idealmente, el destino es mantenido en una máquina separada en una situación remota para propósito de recuperación de desastres.

Figura 7.4: Arquitectura de replicación avanzada

Bajo AR, las copias múltiples de bases de datos o subconjuntos específicos son escritas concurrentemente y se mantienen sincronizadas casi en tiempo real. Una configuración así se denomina configuración multi-maestro (porque existen múltiples copias maestras). Si no se desea sincronización inmediata, puede tomarse un modelo dirigido por eventos para propagar las transacciones de un maestro a los otros. Por ejemplo, la propagación puede estar basada en tiempo, produciéndose durante horas específicas de poco uso. Si se está usando la replicación para propósitos de recuperación de fallos, sin embargo, la sincronización debería ser inmediata. Por ello, cada copia de la base de datos debería de mantenerse de manera peer-to-peer. Todas las escrituras inicialmente se almacenan de forma local, y luego se remiten a cada base de datos de destino utilizando el mecanismo push, en oposición a la replicación simple de instantáneas que se obtiene al tirar (pull) de los datos desde la base de datos origen.

Cada transacción se propaga de forma consistente para prevenir violaciones de la integridad de los datos. Si se producen violaciones o conflictos de integridad, se llevan a cabo los esquemas específicos para resolución de conflictos. Éstos pueden producirse por una variedad de razones. Por ejemplo, si distintos usuarios efectúan cambios en la misma fila en cada base de datos, existirá un conflicto. Una violación de clave única es otro ejemplo de estos conflictos. Los conflictos deben ser detectados y resueltos amigablemente. AR ofrece potentes algoritmos para la detección de conflictos y su resolución. La resolución de conflictos puede ser consistente o variar al nivel de segmento (tabla) o incluso columna. Hay disponibles múltiples técnicas de resolución de conflictos, como utilizar el último de los cambios, usar el primero de los cambios, utilizar los cambios específicos a una cierta sede/base de datos, etc.

A medida que las transacciones van remitiéndo, si una base de datos destino específica no está disponible, las transacciones son retenidas en el origen en la cola diferida. Cuando la base de datos de destino está disponible otra vez, se aplican en ella las transacciones. La falta de disponibilidad de una o más bases de datos destino no evitan que las transacciones sean propagadas a las restantes copias de la base de datos.

Tanto las sentencias DML como las DDL se propagan entre todas las maestras. AR tradicionalmente ha usado desencadenadores (triggers), colas asíncronas y varias tablas periódicas para implementar distintos esquemas de replicación. La replicación basada en desencadenadores es efectiva en ciertos escenarios.

Tradicionalmente, el enfoque basado en desencadenadores en AR es disuasorio, evitando que las sedes con una fuerte actividad puedan usarlo eficientemente sin una degradación significativa del rendimiento. AR en Oracle usa desencadenadores y paquetes internos. Los desencadenadores y paquetes internos son módulos de código en C enlazados en el núcleo de Oracle. Esto hace el código relativamente más a prueba de manipulación (con seguridad elevada), así como ligero y eficiente, permitiendo que la implementación sea rápida y escalable. No se configuran ni mantienen componentes externos. Al no

generarse paquetes ni disparadores, pueden ser instanciados y ejecutados con mayor rapidez. La propagación de datos es manejada mediante el protocolo de flujo directo, en lugar de mediante el igualmente fiable, pero menos eficaz, protocolo de confirmación en dos fases.

En el caso de AR, durante el fallo de una copia específica de la base de datos, la causa del fallo debe determinarse y la base de datos recuperarse/reonstruirse desde la última copia o desde salvaguardas. Como se indicó previamente, existe la posibilidad de una pérdida de datos (las escrituras más recientes) durante ese fallo. Siempre que una copia específica de la base de datos falla, las otras copias continúan funcionando a menos que se produzca un desastre mayor en cuyo caso todas las copias existentes son descartadas. Las posibilidades de que esto ocurra son remotas. Durante estas situaciones, el intervalo de fuera de servicio es significativo porque la base de datos tiene que reconstruirse usando la última salvaguarda disponible. Todo el tráfico de clientes/usuarios tiene que redirigirse a través de TAF o Net8 a copias supervivientes de la base de datos. 

Ventajas de la replicación avanzada

AR ofrece las siguientes ventajas:

Todas las bases de datos mantenidas por AR pueden mantenerse abiertas y en uso concurrente.

AR puede utilizarse para recuperación de desastres teniendo una copia de la base de datos mantenida en una sede remota.

Existe independencia de hardware ya que las máquinas en que se crean las bases de datos pueden ser de distintos fabricantes, plataformas y versiones de SO.

Se han efectuado mejoras a Oracle Enterprise Manager para simplificar la configuración y administración de bases de datos replicadas.

Desventajas de la replicación avanzada

AR tiene las siguientes desventajas:

La propagación podría no ser siempre inmediata. Los cambios de datos en una base de datos pueden no ser visibles inmediatamente en las otras bases de datos.

Durante desastres, existe una posibilidad de alguna pérdida de datos porque la base de datos de una sede puede destruirse antes de que los últimos cambios se hayan propagado. Si la base de datos de una sede falla, pero no es destruida, la pérdida de datos pordría ser temporal y todas las copias de la base de datos pueden sincronizarse una vez que la base de datos se recupere del fallo.

Los mecanismos de resolución de conflictos deben ser bien planificados y tener en cuenta escenarios en los que puede escribirse directamente en las copias de la base de datos para prevenir corrupción lógica de los datos.

7.2.1.5 Combinación de soluciones

Cada una de las opciones de alta disponibilidad ofrece protección contra ciertos tipos de fallos. A veces, la mejor opción es combinar dos o más de las soluciones y prevenir una amplia variedad de situaciones causantes de paros. Por ejemplo, usando RAC nos protegemos contra fallos de nodos locales solamente, pero usándolo con ODG obtenemos una protección adicional contra escenarios de desastres, como una pérdida completa del centro de datos.

 Microsoft SQL Server

Disponibilidad es un término que describe los períodos que está operativo un determinado sistema informático. Así se pueden determinar las horas en las que se espera que los usuarios puedan tener acceso al sistema, teniendo en cuenta los períodos programados de no disponibilidad debidos al mantenimiento o actualización del sistema.

Una de las tareas clave en la administración de un sistema o aplicación consiste en tomar todas las precauciones para reducir al mínimo el tiempo de parada no programado. Los cortes de servicio no programados provocan la frustración de los usuarios, pueden reducir su productividad y, en algunos casos, pueden tener un efecto significativo en la marcha de la empresa. Por ejemplo, en el caso de una solución de comercio electrónico, la falta de disponibilidad producirá, casi con

certeza, la pérdida de ingresos y, si se produce con frecuencia, puede hacer que los clientes dejen de acudir al sitio.

Los aspectos de disponibilidad se suelen tratar, a menudo, junto con las posibilidades de escalabilidad de una solución. Mientras que la disponibilidad trata de resolver el problema que supone proporcionar acceso a la aplicación dutante un período aceptable, la escalabilidad está relacionada con el problema asociado a proporcionar acceso simultáneo a un número aceptable de usuarios.

Hay dos métodos principales para aumentar la escalabilidad: el uso de procesadores más rápidos o el uso de un mayor número de procesadores.

7.2.2.1 Escalabilidad

Los métodos de crecimiento tratan de aumentar el número de usuarios simultáneos a los que puede dar servicio un servidor individual. Normalmente, para conseguir esto se agregan nuevos recursos hardware al servidor. 

El aumento de la memoria RAM instalada en un servidor puede mejorar mucho su capacidad para procesar con mayor rapidez las solicitudes que recibe. A menudo, este sistema sencillo y relativamente económico puede mejorar el rendimiento y la escalabilidad del sistema. 

El multiproceso permite ejecutar en paralelo varios subprocesos. La capacidad de Microsoft Windows 2000 para usar multiproceso simétrico (SMP) permite instalar varios procesadores en el equipo.

Un método alternativo para aumentar la escalabilidad consiste en distribuir la carga de proceso entre varios servidores. Puede usar un sistema denominado balanceo de carga para asegurarse de que las tareas de proceso se distribuyen por igual entre todos ellos.

Hay varios sistemas para aumentar la escalabilidad de las soluciones de SQL Server por medio de la instalación de servidores adicionales. Los sistemas de replicación y los servidores de reserva mejoran la escalabilidad y la disponibilidad, mientras que las federaciones de servidores

suponen una mejora en cuanto a escalabilidad, aunque disminuyen la disponibilidad. 

La replicación puede usarse para distribuir los datos entre varios equipos de la empresa donde se ejecuta SQL Server. Esto permite que los usuarios muy alejados geográficamente puedan tener acceso a una aplicación de base de datos sin que necesiten una conexión permanente con la instalación central. Este sistema permite mejorar la escalabilidad global de una solución ya que distribuye la carga de proceso.

También puede mejorar la disponibilidad ya que permite que los usuarios trabajen con sus copias locales de datos, aun en el caso de que la base de datos central no esté disponible. 

Los servidores de reserva de solo lectura son copias exactas de los servidores de producción de la base de datos. Se puede usar un servidor de reserva como origen de datos de sólo lectura para la generación de informes y otras operaciones de sólo lectura, con lo que se descarga de parte del trabajo del servidor de producción y se mejora la escalabilidad. También mejora la disponibilidad, ya que, en el caso de que el servidor de producción quede fuera de servicio, el servidor de reserva puede tomar su lugar. 

Las federaciones de servidores están formadas por varios equipos con SQL Server donde cada uno contiene un subconjunto de una tabla de datos. Se pueden consultar y actualizar las tablas por separado por medio de una vista dividida y actualizable que muestra al usuario una única tabla virtual. Este sistema mejora la escalabilidad aunque tiene un efecto desfavorable en la disponibilidad ya que introduce varios puntos donde se pueden producir errores.

7.2.2.2 Aumentar la disponibilidad mediante Microsoft .NET Enterprise Server

Microsoft .NET Enterprise Server [16] es una familia completa de aplicaciones de servidor que permite crear, distribuir y administrar soluciones Web integradas y escalables. Una aplicación se divide en tres capas o más, y se reparte entre varios equipos. Cada capa se puede mantener y configurar de forma independiente, lo que permite un alto grado de flexibilidad en cuanto al diseño y administración de la

aplicación. Hay varias formas de optimizar la disponibilidad en cada una de las capas de la aplicación. 

Figura 7.5: Modelo de 3 capas

Capa de presentación

La capa de presentación proporciona los servicios de software que permiten a los usuarios usar la aplicación. Puede tratarse de una aplicación Windows instalada en el equipo del usuario o una aplicación Web a la que tienen acceso los usuarios por medio de un explorador.

Una aplicación Windows instalada de forma local estará disponible siempre mientras la instalación no sufra ningún daño. En una red Windows 2000, puede usar Windows Installer para lograr que las instalaciones dañadas se reparen automáticamente y sea posible instalar a petición componentes adicionales.

Para mejorar la disponibilidad de una aplicación Web, puede distribuir el sitio Web en varios servidores. Puede usar balanceo de carga en la red Windows 2000 para crear un grupo de servidores que responda dinámicamente a una petición de cliente en función de la dirección IP de origen. En este caso se asigna a cada servidor del grupo un conjunto de direcciones IP a las que debe responder. Si se produce un error en el servidor, los restantes servidores se reparten las direcciones IP que quedan desatendidas, con lo que el sitio sigue estando disponible. 

Capa de lógica empresarial

La capa de lógica empresarial contiene el software que implementa las reglas peculiares de una empresa en una aplicación. Normalmente, esta capa está compuesta por componentes del modelo de objetos componentes (COM, Componente Object Model) que contienen las reglas de la empresa.

Se puede lograr la máxima disponibilidad de la capa de lógica empresarial con grupos de servidores divididos en clústeres y administrados mediante Application Center 2000. Además,Application Center 2000 proporciona balanceo de de la carga de componentes (CLB, Component Load Balancing), una de las características de Servicios de componentes, lo que permite distribuir los componentes en varios servidores y equilibrar de forma dinámica su carga en función de la disponibilidad y trabajo de cada uno.

En el caso de procesos asincrónicos de empresa que no precisen de una respuesta inmediata, se pueden usar los componentes de colas de los servicios de componentes para que sea posible el acceso a la lógica empresarial aunque el servidor de base de datos no esté disponible. 

Capa de datos

En una aplicación de tres capas, las bases de datos SQL Server forman parte de la capa de datos. La disponibilidad de esta capa se puede mejorar de varias formas.

En el caso de una instalación de servidor único, se pueden emplear soluciones con tolerancia a fallos mediante tecnología RAID. Windows 2000 es compatible con RAID nivel 1 (discos espejo) y RAID nivel 5 (creación de bandas de disco con paridad). Ambos sistemas se pueden usar para garantizar la disponibilidad de la base de datos completa incluso en el caso de un error de disco.

Si hay más de un servidor instalado, se puede usar la replicación de datos para hacer que la base de datos esté disponible en varios puntos alejados o, incluso, al alcance de usuarios sin conexión. Así se permite que los usuarios usen la aplicación de base de datos cuando no se puede establecer una conexión con el servidor de publicación.

Para alcanzar un altísimo grado de disponibilidad se puede usar la organización por clústeres con conmutación por error. Este sistema se basa en las capacidades del uso de clústeres de Windows 2000 y permite crear un servidor virtual formado por varios equipos físicos. En el caso de que se produzca un error en un servidor, los restantes servidores del clúster hacen que la base de datos siga estando disponible.

Finalmente, se puede usar un servidor de reserva que contenga una copia completa del servidor de producción de la base de datos, que se podrá comenzar a utilizar en el caso de que se produzca un error en el servidor. Este servidor de reserva se mantiene sincronizado con el servidor de producción mediante un sistema denominado trasvase de registros en el que los registros de transacciones del servidor de producción se aplican al servidor de reserva.

7.2.2.3 Clústeres con conmutación por error

Un clúster está formado por dos o más equipos independientes que trabajan conjuntamente como si fueran un único equipo. La organización por clústeres [16] constituye una eficaz forma de aumentar la disponibilidad ya que permite la conmutación en caso de error. Si un miembro del clúster tiene un error, los restantes miembros garantizan que las operaciones no se vean afectadas. 

Figura 7.6: Organización por clústeres de Windows

Componentes de un clúster

Tenga en cuenta los siguientes hechos acerca de la organización por clústeres de Windows:

Los servidores miembros de un clúster se conocen como nodos.

Los nodos de un clúster deben estar vinculados entre sí por medio de un vínculo de comunicación de red independiente.

Cada nodo debe disponer de una conexión a uno o varios discos compartidos (RAID), donde se almacenan los datos del clúster.

Los recursos, como aplicaciones o unidades lógicas, se combinan en grupos de recursos a los que se asigna un nodo principal. Este nodo es el predeterminado para el acceso a esos recursos

Conmutación por error

Los nodos de un clúster usan software de organización por clústeres para mantener la disponibilidad y realizar la conmutación en caso de error. El Monitor de recursos realiza la comunicación entre el Servicio de clúster y los recursos de las aplicaciones en el clúster. El Servicio de clúster controla la comunicación entre los nodos y realiza la conmutación en caso de error.

En el caso de que haya un error en una aplicación debido a un error del equipo, el Servicio de clúster tratará de reiniciar la aplicación. Si no lo consigue, reiniciará la aplicación en otro nodo del clúster, al que moverá todos los recursos de esa aplicación.

Si se produce un error en un nodo, el Servicio de clúster reparte automáticamente el trabajo que realizaba ese nodo entre los restantes miembros del clúster. 

Clústeres con conmutación por error

La organización por clústeres con conmutación por error de SQL Server está diseñada para que trabaje conjuntamente con la organización por clústeres de Windows. Cuando se instala la organización por clústeres con conmutación por

error en un clúster, permite que varios equipos SQL Server aparezcan como un único servidor virtual.

Un clúster con conmutación por error de SQL Server 2000 puede incluir uno o varios servidores virtuales. Cada servidor virtual consta de uno o varios nodos. Puede crear servidores virtuales durante la instalación de SQL Server y puede instalar un servidor virtual para cada grupo de recursos del clúster subyacente de Windows.

En un clúster con conmutación por error de SQL Server, cada servidor virtual debe tener asignado un nombre de red de forma que los clientes puedan tener acceso a él a través de la red. Un servidor virtual puede tener asignadas varias direcciones IP. Puede asignar distintas direcciones IP para todas las subredes disponibles, con lo que se garantiza la conexión a la red aún en el caso de que ocurra un error en un adaptador de red o enrutador. 

Organización por clústeres activo-pasivo

Puede configurar SQL Server en un clúster de forma que sólo esté activa una copia de SQL Server en cualquier momento. El otro servidor SQL Server está pasivo y sólo se activa cuando se produce un error en el nodo principal. En el caso de una conmutación por error, el nodo secundario se hace cargo de los recursos y carga de trabajo del nodo principal. Esta configuración ofrece protección frente a errores de sistema, al tiempo que proporciona un rendimiento óptimo.

Figura 7.7: Organización por clústeres activo-pasivo

La configuración por clústeres con conmutación por error activo-pasivo se puede realizar siempre que se disponga de los siguientes componentes y se cumplan las condiciones mencionadas:

El disco de cada nodo contiene una copia de Windows 2000 Advanced Server o Windows 2000 DataCenter Server. El disco también debe tener instalado Organización por clústeres de Windows.

Una copia de SQL Server debe estar instalada en el disco SCSI o en la matriz de discos que comparten ambos nodos.

Hay una conexión de red que vincula los dos servidores físicos.

Se ha creado un servidor virtual que representa el conjunto formado por los dos servidores físicos. Puede crear un servidor virtual mediante el Asistente para clústeres con conmutación por error.

Los clientes que se conectan a este servidor virtual no saben a qué servidor físico activo están conectados. 

Organización por clústeres activo-activo

En entornos en los que hay varias aplicaciones de bases de datos, se puede usar la organización por clústeres activo-activo para mejorar la disponibilidad de las aplicaciones al tiempo que se ejecutan en un host distinto par aumentar el rendimiento. En una configuración por clústeres con conmutación por error activo-activo, cada nodo ejecuta una o varias copias de SQL Server. De esta forma, es posible que cada nodo actúe como servidor principal de uno o varios servidores virtuales, y como servidor secundario del resto de los servidores.

Figura 7.8: Organización por clústeres activo-activo

Esta configuración utiliza al máximo ambos nodos, aunque mantiene la posibilidad de conmutación por error. Sin embargo, si se produce la conmutación por error, el

rendimiento general se verá afectado ya que un nodo debe hacer frente a la carga de trabajo de ambos nodos.

La configuración por clústeres con conmutación por error activo-activo se puede realizar siempre que se disponga de los siguientes componentes y se cumplan las condiciones mencionadas:

El disco de cada nodo mantiene una copia de Windows 2000 Advanced Server o Windows 2000 Datacenter Server. El disco también debe tener instalada la organización por clústeres con conmutación por error.

Debe haber dos discos físicos SCSI o matrices RAID de hardware compartidos en un bus SCSI compartido.

Debe haber instalada una copia de SQL Server en cada uno de los discos compartidos.

Debe haber al menos dos conexiones de red que vinculen los dos servidores físicos.

Se deben haber instalado dos servidores virtuales, cada uno de los cuales debe representar al conjunto formado por los dos servidores físicos. Los clientes se pueden conectar a cualquiera de los servidores virtuales.

7.2.2.4 Servidores de reserva y trasvase de registros

Un servidor de reserva [16] es un servidor físico independiente que contiene una copia exacta del servidor de producción. Si se produce un error en el servidor de producción, se puede realizar inmediatamente la conmutación al servidor de reserva, con lo que se reduce al mínimo el tiempo de inactividad y se alcanza un alto grado de disponibilidad.

Un servidor de reserva es un segundo servidor que refleja el contenido del servidor principal. Se puede usar el servidor de reserva para sustituir al servidor principal cuando se produce un error en éste. También se puede usar como una copia de sólo lectura de la base de datos, con lo que se descarga parte del trabajo del servidor principal.

Para mantener sincronizado el servidor de reserva con el servidor principal puede copiar y cargar los registros de transacciones del servidor principal al servidor de reserva. Debe comprobar que SQL Server utiliza el modelo de

recuperación completa para que se realicen las copias de seguridad del registro de transacciones.

El transvase de registros automatiza el proceso de sincronización mediante el uso de trabajos de SQL Server Agent. La secuencia de sucesos que componen el transvase de registros incluye la realización de copias de seguridad de los registros de transacciones de la base de datos principal, la copia de éstos a una ubicación secundaria y su restauración en la base de datos secundaria. En concreto:

SQL Server Agent realiza una copia de seguridad del registro de transacciones del servidor principal y le asigna un nombre basado en la fecha y hora actuales.

El SQL Server Agent del servidor de reserva copia a una carpeta del del servidor secundario la copia de seguridad del registro de transacciones.

El SQL Server Agent del servidor secundario ejecuta un trabajo de carga para restaurar el registro de transacciones en la base de datos del servidor de reserva.