Modelos de Alta Disponibilidad aplicados al mantenimiento de una Base de Datos

1. David Herrero
SISTEMAS DE INFORMACIÓN AVANZADOS 01/12/2013
MODELOS DE ALTA
DISPONIBILIDAD

2. PÁGINA 1
Contenido
¿Qué significa Alta Disponibilidad? ..............................................................................................................2
Características de la Alta Disponibilidad......................................................................................................2
Alta Disponibilidad en BBDD ........................................................................................................................3
Topologías de cluster ................................................................................................................................. 4
Ejemplo de Máxima Disponibilidad ..............................................................................................................5
Implementación de Alta Disponibilidad en algunos gestores de BBDD ...................................................5
Oracle ...........................................................................................................................................................5
Microsoft SQL Server................................................................................................................................. 6
MySQL..........................................................................................................................................................7
Bibliografía
 http://technet.microsoft.com/es-es/library/ms190202.aspx
 http://www.uv.mx/universo/471/infgral/infgral_13.html
 http://en.wikipedia.org/wiki/High_availability
 http://www.oracle.com/us/products/database/high-
availability/overview/index.html
 http://en.wikipedia.org/wiki/High-availability_cluster
 http://dev.mysql.com/doc/refman/5.0/en/ha-overview.html

3. PÁGINA 2
¿Qué significa Alta Disponibilidad?
Las bases de datos y el auge de Internet han permitido la colaboración y el intercambio desde
cualquier parte del mundo, ampliando el alcance de las aplicaciones de bases de datos en todas las
organizaciones y comunidades.
Este alcance resalta la importancia de la alta disponibilidad (poder disponer de un servicio de forma
casi continua) en soluciones de gestión de datos.
Tanto las pequeñas como las grandes empresas tienen usuarios de todo el mundo que necesitan
acceso a los datos las 24 horas del día, independientemente de que sea de noche en una parte del
mundo, o que sean días festivos, etc. Sin este acceso a los datos las operaciones pueden llegar a
detenerse y perder tanto ingresos como reputación.
Cada vez más, la disponibilidad se mide en euros, y no solo en tiempo, ya que el tiempo que un
servicio está detenido es dinero que la empresa deja de ingresar. La alta disponibilidad (gestionada
por departamento de IT) proporciona una ventaja competitiva, aumenta la productividad y el valor
de la empresa.
Si un servicio no está disponible puede que toda la empresa deba detenerse, y aquí es donde entra en
juego la alta disponibilidad, que consiste en mantener todos los servicios que ofrece la TI disponibles
24/7 o al menos con la mínima interrupción posible.
A modo de ejemplo se dice que un servicio que esté 99,9 % del tiempo disponible hace perder a la
empresa 8,76 horas/ año, y uno que esté 99,999% solo 5,26 minutos/año.
Características de la Alta Disponibilidad
Las principales características de una un Modelo de Alta Disponibilidad deben ser:
 Fiabilidad: los componentes HW y SW del sistema deben ser fiables. Es la parte crítica de
una implementación de Alta Disponibilidad. No se debe escatimar gastos en esta parte si se
desea implementar un modelo de Alta Disponibilidad de forma correcta.
 Recuperación: puede haber muchas opciones para recuperarse de un fracaso si ocurre
alguno, es importante determinar qué tipo de fallos pueden ocurrir y estableces
procedimientos para recuperarse antes ellos.
 Detección de errores: si un componente de la arquitectura falla, la rápida detección del
mismo minimizará enormemente el daño producido. La monitorización del estado del
servicio es imprescindible para la detección rápida de los fallos.
 Continuas operaciones: las actividades del mantenimiento que se realicen sobre el servicio
deben ser transparentes para el usuario.
Uno de los retos en el diseño de una solución de Alta Disponibilidad es examinar y abordad todas las
posibles causas de una posible inactividad. Hay que considerar tanto las causas de tiempo de
inactividad planificado (mantenimiento periódico) como el no planificado (cortes de luz, fallos SW o
HW).

4. PÁGINA 3
Alta Disponibilidad en BBDD
El acceso a datos dentro de la organización , y por lo tanto el acceso a las BBDD son especialmente
críticos ya que la mayoría de las aplicaciones trabajan siempre contra una BBDD , por lo tanto si esta
se queda inaccesible, el resto de servicio también caerán y se producirá un fallo grave.
Por lo tanto, uno de los principales objetivos del DBA, es conseguir que el la BD esté 24/7 disponible,
siguiendo todas las buenas prácticas que se han descrito antes: fiabilidad, recuperación, detección de
errores y continuas operaciones.
Existen varios modelos para conseguir esto dentro de las BBDD, en todos los casos se necesita una
inversión en HW más o menos grande, y de un SW capaz de realizar las distintas operaciones para
mantener la BBDD siempre activa o con una tasa de actividad lo suficientemente alta.
Si solo se tienen en cuenta soluciones de alta disponibilidad basadas en HW, resulta casi imposible
reducir los tiempos de inactividad relacionados con actualizaciones y parches, evitar errores
humanos, detectar y recuperarse de daños físicos y garantizar la conmutación por error de los
clientes de una aplicación en el caso de una interrupción.
En casi todos los casos las soluciones HW consisten en una replicación total o parcial, o el uso de
un clúster.
En la siguiente tabla se muestran 4 modelos de Alta Disponibilidad y sus especificaciones.
Modelo Comportamiento
del segundo nodo
Protección de datos Tiempo de fallo
Carga balanceada Los nodos primario y
secundario están
activos siempre, y
procesas las peticiones
del sistema en
paralelo.
La replicación de los
datos es bidireccional,
todos los datos están
en ambos sistemas.
Sin tiempo de fallo.
Hot standby En los nodos primario
y secundario se
encuentra todo el SW
necesario, el nodo
secundario está
corriendo pero no
procesa peticiones
hasta que el nodo
primario falla.
Los datos están
replicados en ambos
nodos, y contienen
datos idénticos.
Unos segundos.
Warm standby En el nodo secundario
el SW está instalado
pero no está
corriendo. Si se
produce un fallo en el
nodo primario el nodo
secundario inicia los
componentes del SW.
Este proceso se
automatiza con un
Los datos se copian al
nodo secundario de
forma regular o están
alojados en un disco
compartido.
Unos minutos.

5. PÁGINA 4
“cluster manager”.
Cold standby El nodo secundario
actúa como una copia
de seguridad idéntica
del primero. El nodo
secundario está
configurado pero se
encuentra totalmente
apagado hasta que se
produce un fallo del
primero, en ese
momento entra en
acción hasta que el
nodo primario es
reparado.
Los datos pueden ser
copiados en un
sistema de
almacenamiento y
restaurarlos en el
nodo secundario
cuando es necesario.
Unas horas.
Topologías de cluster
Como se ha dicho antes, una de las formas de conseguir Alta Disponibilidad es usando los clusters,
las topologías en las que se pueden usar son las siguientes : N+1, N+M, N-to-1, N-to-N:
 N+1: un único nodo secundario es activado para tomar el rol del nodo fallido. Si el nodo
primario realiza actividades muy diferentes (web server, BBDD, etc) el nodo secundario
deberá ser capaz de asumir todas las actividades del nodo fallido.
 N+M: si un único cluster realiza muchos servicios, puede que una configuración N+1 no sea
viable ya que el nodo secundario puede que no sea capaz de realizar todos los servicios del
nodo fallido. En estos casos se puede usar la configuración con M nodos secundarios en
standby. Este modelo es más caro que el anterior pero puede ser necesario en algunas
situaciones.
 N-to-1: un nodo secundario se activa temporalmente hasta que el primario es reparado,
cuando el nodo primario es reparado los servicios deben reactivarse para mantener la Alta
Disponibilidad.
 N-to-N: se redistribuye los servicios desde los nodos fallidos hasta nodos secundarios
disponibles. No se necesita un nodo en standby pero se necesita un extra de capacidad en el
resto de los nodos activos.

6. PÁGINA 5
Ejemplo de Máxima Disponibilidad
Ilustración 1 Máxima Disponibilidad
Los dos sitios deberían estar situados en distintas localizaciones físicas para asegurar la Máxima
Disponibilidad. En el sitio principal existe un modelo de alta disponibilidad (uso de clúster y
replicación de HW), mientras que el sitio de respaldo no tiene Alta Disponibilidad. Sin embargo al
usarlos de forma complementaria se consigue un modelo de Máxima Disponibilidad.
Implementación de Alta Disponibilidad en algunos gestores de
BBDD
Ahora se verán algunos ejemplos de cómo los distintos motores de BBDD como Oracle, SQLServer
implementan los modelos de Alta Disponibilidad en sus productos.
Oracle
Los tres principios básicos de la visión de alta disponibilidad de Oracle son:
 Aprovechamiento de la protección de datos optimizada para Oracle: la solución Oracle Data
Guard puede detectar y detener la propagación de bloques dañados hacia los clientes. De
igual manera la solución de backup y recuperación (RMAN) de Oracle posibilita la
recuperación de bloques específicos. Active Data Guard permite abrir las bases de datos
físicas de reserva para acceder a ellas directamente.

7. PÁGINA 6
 Alta disponibilidad integrada en las aplicaciones: Las tecnologías innovadoras Flashback de
Oracle se desempeñan en los objetivos comerciales, por ejemplo, en la reparación de tablas
o en la recuperación de transacciones específicas.
 Arquitectura integrada, automatizada y abierta: Las soluciones de alta disponibilidad de
Oracle están disponibles como funciones integradas de la base de datos, por lo que no se
requiere de una integración adicional con tecnologías de terceros. Además, todas las
funciones pueden administrarse a través de la interfaz de administración de Oracle
Enterprise Manager Grid Control. Oracle también ofrece automatización en cada paso para
evitar que se cometan errores típicos y habituales en las configuraciones manuales.
Ilustración 2 Oracle MAA
Microsoft SQL Server
Microsoft SQL Server presenta algunas opciones que permiten implementar la Alta Disponibilidad
en un servidor de base de datos. A continuación una breve descripción de dichas alternativas.
 Reflejo de base de datos: la idea principal es mantener una base de datos sincronizada con
una copia en un servidor diferente para ofrecer la alta disponibilidad por la redundancia de
la información. Para implementar este modelo es necesario contar con al menos dos
instancias del servicio de base de datos de Microsoft SQL Server; en una de las instancias se
tiene la base de datos con la información actualizada y vigente (servidor principal), y en
otra, una copia de la información, la cual se encuentra en modo de espera (servidor
reflejado). En cuanto se pierde comunicación con el servidor principal, el reflejado puede
iniciar como servidor de espera activa.
 Trasvase de registros: En este modelo se tiene un servidor principal que almacena la base de
datos activa y uno o varios servidores que almacenan copias de la base de datos. Las copias
de la base de datos se pueden utilizar para la elaboración de consultas y reportes que no
requieren la información actualizada en tiempo real. Para la actualización de las copias se
programan transacciones en periodos constantes. Cuando ocurre un error en el servidor
principal puede utilizarse la base de datos secundaria sólo si está totalmente actualizada.

8. PÁGINA 7
 Replicación: Es un modelo de publicación y suscripción, es decir, existe un servidor
principal (publicador) que distribuye los datos en otros servidores secundarios
(suscriptores), debido a que las bases de datos secundarias se están actualizando
constantemente se puede ofrecer disponibilidad en tiempo real.
MySQL
Existen varias posibilidades nativas:
 Replicación: basada en transferencia y aplicación de log Binario del nodo master al los nodos
slaves, en forma asincrónica o semisinónica. Es en un solo sentido, un slave puede tener solo
un master.
 Storage compartido:
 Cluster:
Ilustración 3 MySQL
Y varias provistas por terceros como MMM Multi-Master Replication Manager , esta utilidad
consta de una serie de scripts y demonios que se encargan de : monitorización de la replicación,
monitorización de los hosts, gestión del failover, balanceo de IPs entre los nodos, gestión de
escritura/lectura. Este servicio se debe instalar en un nodo diferente del cluseter y se encargará de
conectarse a cada nodo y comprobar el estado y ejecutar las ordenes que se le indiquen.