Arquitectura de Sistemas: Ejercicios: Recuperacin de desastres

Ejercicios: Recuperacin de desastres

Guillermo Prez Trabado 2016

Arquitectura de Sistemas

Depto. de Arquitectura de Computadores - Universidad de Mlaga

Soluciones
1. Considera una infraestructura tolerante a desastres clasificada como tier 5 donde la
aplicacin (business logic layer) se encarga de conectar con dos servidores de base
de datos (data layer) simultneamente para mantener dos copias.
a. Razona lo que entiendes que ocurre en este esquema en el caso de que una de
las dos bases de datos falle durante un periodo prolongado de tiempo.
La aplicacin gestiona la conexin simultnea a dos bases de datos,
actualizando ambas a la vez y contemplando el caso de que una falle, de forma
que el funcionamiento contina automticamente con una sola de ellas.

b. Cmo quedan las dos bases de datos en el momento de restablecer el

funcionamiento de la que fall?
Al restablecerse la conexin, el problema es que una de las bases de datos
contendr datos obsoletos al no haberse podido actualizar a la vez que la otra.
Al recaer en la aplicacin la responsabilidad de la actualizacin simultnea,
no hay ningn mecanismo en las propias bases de datos para restablecer la
coherencia de forma automtica.
c. Qu estrategias se podran aplicar para solucionar la situacin anterior?
La librera de conexin a la base de datos debera contener algn mecanismo
de control de la coherencia durante la desconexin de una de las dos bases de
Universidad de Mlaga: Master Univ. Ingeniera Informtica
datos, de forma que recordara cules son los registros que se han actualizado
durante la desconexin y permitiera restablecer la coherencia.
Esto complica la propia aplicacin ya que no solo tiene que ocuparse del
trfico de datos con la base de datos sino tambin del trfico de replicacin
entre las bases de datos.

2. Considera ahora una infraestructura tolerante a desastres clasificada como tier 6

donde la aplicacin (business logic layer) se encarga de conectar con un servidor de
base de datos (data layer) que est sincronizado con un segundo servidor a travs de
un sistema de mirroring de disco de bajo nivel tal como DRBD.

Guillermo Prez Trabado 2016 1

 Arquitectura de Sistemas: Ejercicios: Recuperacin de desastres

a. Si el tier de I/O del site A queda destruido, explica cmo habra que proceder
para que el tier de clculo (business logic layer) contine en servicio.
El nodo de I/O del site B debera pasar a modo primario y montar el sistema de
ficheros en el sistema operativo, de forma que permita modificaciones locales
de su contenido. El servidor DBMS del site B debe ponerse en marcha. Por
ltimo, los clientes deben conectar a este site, por ejemplo mediante un servicio
de alta disponibilidad que asigne una direccin de servicio IP flotante al
servidor del site B.
b. Si la conexin WAN queda interrumpida durante un largo periodo, explica
cmo habra que proceder 1) en el momento de la interrupcin, y 2) en el
momento del restablecimiento de la conexin. Considera este caso como
independiente del anterior, es decir, que es otro desastre distinto.
Al perder la conexin, el nodo activo debe dejar de sincronizar y pasar
actualizando tan solo la copia local.
En el momento de la reconexin, DRBD detecta la reaparicin del nodo
secundario y pone en marcha la sincronizacin de forma automtica. La
sincronizacin enva al site B todos los cambios pasados hasta actualizar
completamente al secundario. Durante la resincronizacin, el site A puede
seguir operando normalmente ya que las nuevas escrituras se unen a la lista de
cambios a sincronizar.
c. Si el site A queda totalmente aislado de internet y no puede comunicarse con
todos sus posibles usuarios, explica cmo habra que proceder.
Universidad de Mlaga: Master Univ. Ingeniera Informtica

Como el site A no es til, es el site B el que debe atender a los usuarios y por
tanto debe convertirse en el nodo primario en el cual se actualizan los datos.
Por tanto, el nodo de I/O primario del site A debe pasar inmediatamente a
secundario, incluso si no tiene posibilidad de comunicarse con el nodo de I/O
del site B. El nodo de I/O del site B debe pasar a primario y las aplicaciones
deben conectarse a dicho nodo.
3. Debate cules son los aspectos positivos y negativos de las infraestructuras diseadas
para conseguir un RPO y RTO muy reducido para sus servicios.
El aspecto positivo es que la prdida de datos y de tiempo es mnima, y por
tanto se minimiza el impacto sobre las actividades de la empresa.
El aspecto negativo es que para conseguir reducir RPO y RTO se necesitan
soluciones y tecnologas que requieren una inversin econmica ms alta tanto
en hardware como en horas de trabajo del personal.

2 Guillermo Prez Trabado 2016

 Arquitectura de Sistemas: Ejercicios: Recuperacin de desastres

4. Por qu no es adecuado definir un RPO y RTO lo ms reducidos posibles y se llega a

un punto de equilibrio definido en el SLA? Cules son las variables que tienen que
alcanzar el equilibrio al disear el SLA para el proyecto de una infraestructura?
Las dos variables principales son el coste econmico de la solucin necesaria
para lograr un RTO Y RPO y el impacto econmico en el negocio que se
produca dados dichos RTO y RPO. El coste econmico de la solucin debe
ser inferior al impacto econmico de los posibles daos.
5. Considera un site que hace backup de su servidor de base de datos cada madrugada a
la 01:00AM en un dispositivo removible (cinta magntica) que se retira de la sala de
datos y enva por mensajera a una localizacin externa a las 8:10AM. El RPO definido
es de 24h.
a. Si ocurre un desastre que destruye completamente las instalaciones a las
9:00AM, cul es el periodo de tiempo del que se han perdido los datos de la
base de datos?
Se han perdido datos de 8 horas.
b. Si ocurre el mismo desastre a las 7:00AM, cul es ahora el periodo de tiempo
del que se han perdido datos?
El ltimo backup no haba salido de las instalaciones aun. Se han perdido
datos de 30 horas ya que el ltimo backup existente es de hace 30 horas en el
momento de la catstrofe.
c. Se cumple el RPO en ambos casos?
En el segundo caso no. La frecuencia entre backups no es directamente el RPO,
sino que hay que considerar el caso peor, como en el del ejemplo.
6. Lee estos fragmentos del manual de DRBD sobre la situacin en la que se produce
inconsistencia entre los datos de ambas copias de un volumen de disco cuando ambos
nodos funcionan como primario a la vez, permitiendo modificaciones locales mientras
estn desconectados entre si.
Durante la reconexin, DRBD no slo detecta la situacin, sino que permite definir
mecanismos automticos para actuar. En el texto a continuacin se muestran los 4 Universidad de Mlaga: Master Univ. Ingeniera Informtica
modos que pueden definirse para la recuperacin automtica.

Split brain is a situation where, due to temporary failure of all network links
between cluster nodes, and possibly due to intervention by a cluster management
software or human error, both nodes switched to the primary role while
disconnected. This is a potentially harmful state, as it implies that modifications
to the data might have been made on either node, without having been replicated
to the peer. Thus, it is likely in this situation that two diverging sets of data have
been created, which cannot be trivially merged.

DRBD allows for automatic operator notification (by email or other means)
when it detects split brain. See the section called Split brain notification for
details on how to configure this feature.

While the recommended course of action in this scenario is to manually resolve

the split brain and then eliminate its root cause, it may be desirable, in some

Guillermo Prez Trabado 2016 3

 Arquitectura de Sistemas: Ejercicios: Recuperacin de desastres

cases, to automate the process. DRBD has several resolution algorithms

available for doing so:

Discarding modifications made on the younger primary. In this

mode, when the network connection is re-established and split brain is
discovered, DRBD will discard modifications made, in the meantime, on
the node which switched to the primary role last.
Discarding modifications made on the older primary. In this mode,
DRBD will discard modifications made, in the meantime, on the node
which switched to the primary role first.
Discarding modifications on the primary with fewer changes. In this
mode, DRBD will check which of the two nodes has recorded fewer
modifications, and will then discard all modifications made on that host.
Graceful recovery from split brain if one host has had no intermediate
changes. In this mode, if one of the hosts has made no modifications at
all during split brain, DRBD will simply recover gracefully and declare
the split brain resolved. Note that this is a fairly unlikely scenario. Even
if both hosts only mounted the file system on the DRBD block device
(even read-only), the device contents would be modified, ruling out the
possibility of automatic recovery.

Caution

Whether or not automatic split brain recovery is acceptable depends largely

on the individual application. Consider the example of DRBD hosting a
database. The discard modifications from host with fewer changes
approach may be fine for a web application click-through database. By
contrast, it may be totally unacceptable to automatically discard any
modifications made to a financial database, requiring manual recovery in any
split brain event. Consider your application's requirements carefully before
enabling automatic split brain recovery.

a. Lee el texto y razona si es razonable o no usar estos mecanismos de

recuperacin de la coherencia a bajo nivel (replicacin de disco) en el caso
Universidad de Mlaga: Master Univ. Ingeniera Informtica

concreto de que el volumen gestionado por DRBD contenga una base de datos
relacional.
De lo que se deduce por la lectura, la granularidad del proceso de
recuperacin es el contenido completo del volumen (LUN). Eso implica que no
hay posibilidad de aislar e incorporar selectivamente algunas transacciones
sueltas al otro servidor.
b. Compara adems la situacin con la que sera necesaria en caso de tener
replicacin de logs entre dos bases de datos y haber cometido el error de
modificar ambas BD por separado.
En el caso del envo del registro de transacciones a nivel de SGBD, el log de
cada base de datos preserva las transacciones realizadas en cada una de ellas
y su fechas. Es posible extraer del log de cada BD las transacciones que se han
realizado durante el periodo de incoherencia y aplicarlas recprocamente a
cada una de las dos bases de datos por separado.

4 Guillermo Prez Trabado 2016