TEMA 4.
TOLERANCIA A FALLOS EN SISTEMAS DISTRIBUIDOS
1. MOTIVACIÓN DE LA FIBILIDAD DE LOS SISTEMAS
El tiempo de inactividad es el periodo de tiempo en que un sistema (o red) no está disponible para su
uso.
Hay dos tipos de tiempo de inactividad programados y no programados:
Un tiempo de inactividad programado es el resultado de un mantenimiento, que es
inevitable. Esto incluye aplicar parches, actualizar programas o incluso cambios en el
esquema de la base de datos.
Un tiempo de inactividad no programado es causado por un evento imprevisto, como un
fallo de hardware o software. Esto puede suceder debido a cortes de energía o fallos de un
componente.
Los tiempos de inactividad programados generalmente se excluyen de los cálculos de rendimiento.
Una interrupción no planificada no siempre es un desastre. Por ejemplo, que un disco duro falle, o una
fuente de alimentación falle es un incidente y debe ser tratado como tal.
Desastres naturales
Accidentes
Desastres provocados
Desastres políticos
Desastres informáticos
2. PLANES PARA EVITAR ALCANCE DE LOS DESASTRES
Para poder evitar el impacto de los desastres hay que planificar. Podemos contar con planes de
contingencia, de recuperación de desastres y de continuidad del negocio.
Plan de contingencia: los planes de contingencia se orientan a proteger un elemento
específico de tecnología, que es vital para la organización, y poseer control total sobre este,
por ejemplo: un servidor, una aplicación, un dispositivo o un elemento de soporte de
comunicaciones (router, switch, etc).
Plan de recuperación de desastres (DRP): Un plan de recuperación de desastres es un
conjunto estructurado de recursos humanos, técnicos y procedimentales, aprobados por la
dirección para recuperar en el menor tiempo y coste posibles y con los condicionantes y
limitaciones que se tienen, una actividad interrumpida a causa de una emergencia.
Plan de continuidad del negocio: Conjunto de tareas que permite a las organizaciones
continuar su actividad ante una situación que afecte a sus operaciones. Un plan de continuidad
afecta tanto a los sistemas informáticos, como al resto de procesos de la organización.
3. CUESTIONES PARA REALIZAR UN ANÁLISIS DE IMPACTO
¿Qué cuestiones o preguntas se os ocurren que debemos plantearnos a la hora de realizar un análisis
de impacto?
¿Tienes copias de seguridad de toda la información?
¿Qué elementos son más críticos?
¿Están las réplicas en el mismo edificio o fuera?
¿Por qué desastres se puede ver afectado tu empresa? Inundaciones, incendios...
¿Cuántas personas quedarían inactivas ante un desastre?
¿Cómo afecta económicamente una interrupción del servicio informático?
Interdependencia entre la empresa y un proveedor
En definitiva se trata de establecer métricas y valores tangibles:
Ejemplos de valores tangibles:
o Dinero que se deja de percibir
o Coste de vuelta a la normalidad
o Sanciones impuestas por organizamos oficiales
o Penalizaciones contractuales ejercidas por clientes
o Corrupción de materiales perecederos.
o Préstamos necesarios para continuar con la actividad
Ejemplos de valores intangibles:
o Impacto en proveedores
o Fluctuaciones de acciones en bolsa
o Impacto en empleados
o Impacto en la imagen de empresa y/o producto
4. ALTA DISPONIBILIDAD
Alta disponibilidad (HA) es una estrategia de gestión de sistemas para restaurar rápidamente los
servicios esenciales, al producirse un evento en el sistema, componente o aplicación de fallo. Por otro
lado, la alta disponibilidad no es un software específico o un hardware específico, es la suma de
software, hardware y buenas practicas bien documentadas.
De acuerdo con el DRII (Disaster Recovery Institute International), la alta disponibilidad se define
como: “sistemas o aplicaciones que requieren un alto nivel de fiabilidad y disponibilidad. Los
sistemas de alta disponibilidad operan normalmente 24x7 y normalmente necesitan ser construidos
usando redundancia para minimizar el riesgo de una parada debida a fallos en hardware o
comunicación”.
Alta disponibilidad más allá de la disponibilidad del hardware, implica asegurar la disponibilidad de
acceso a la aplicación, con solo una pequeña interrupción, en caso de fallo de alguno de los
componentes del sistema. Los sistemas de HA permiten reiniciar aplicaciones en un hardware
redundante en caso de fallos. El tiempo de interrupción depende principalmente de la recuperabilidad
de la aplicación.
*Se entiende como tiempo de interrupción al tiempo que le cuesta a la aplicación volver a estar
operativa en caso de una parada brusca.
5. ESTRATEGIDAS PARA DISEÑAR UN SISTEMA FIABLE
Sistema fiable
Sistema no redundante (sin copias)
o Evitación / prevención de fallos
Sistema redundante
o Detección de errores (reinicio)
o Sistemas tolerantes a fallos
Redundancia estática: los sistema redundantes están siempre activos. Los dos
programas se ejecutan a la vez.
Redundancia dinámica: los sistema redundantes se activan cuando se detecta
el fallo. El programa solo se va a ejecutar cuando haga falta.
Ejemplo:
Ejemplo de redundancia estática y dinámica desde el punto de vista del software:
Imaginemos que solicitamos que nos hagan un SW, aportamos nuestros requisitos y nos lo entregan.
¿cómo podemos prevenir posibles errores del mismo por defectos en su programación?
Redundancia estática del software: basada en la programación con N versiones.
La programación N-versión se define como la
generación independiente de N (N>=2)
programas, a partir de una misma
especificación. Los programas se ejecutan
concurrentemente, con la misma entrada, y
sus resultados son comparados por un
proceso coordinador. El resultado ha de ser el mismo. Si hay discrepancia, se realiza una votación
entre las N versiones.
Redundancia dinámica en el software: basada en
bloques de recuperación y en programación con N
versiones auto comprobantes .
En la redundancia dinámica en el software, los
componentes redundantes solo se ejecutan cuando se
detecta un error.
6. EJEMPLOS DE MEJORES PRÁCTICAS
Copias de seguridad, recuperación y replicación de datos: Estrategia, pruebas, copias
parciales vs copias completas, etc
Agrupación: En caso de error, la agrupación en clúster puede proporcionar servicios
instantáneos de aplicación de conmutación por error. Un servicio de aplicaciones que es
compatible con clústeres es capaz de invocar recursos desde múltiples servidores, es decir,
vuelve a un servidor secundario si el servidor principal se desconecta. Esto significa que
cualquier nodo puede desconectarse o apagarse de la red, y el resto del clúster continuará
funcionando normalmente, siempre que al menos un nodo sea completamente funcional.
Equilibrio de carda de red: El equilibrio de carga es una forma efectiva de aumentar la
disponibilidad de aplicaciones críticas basadas en la web. Cuando se detectan instancias de
falla del servidor, se reemplazan sin problemas cuando el tráfico se redistribuye
automáticamente a los servidores que aún se están ejecutando.
Soluciones de Failover: La conmutación por error es básicamente un modo operativo de
respaldo, en el cual las funciones de un componente del sistema son asumidas por un sistema
secundario, en caso de que el primario se desconecte, ya sea por falla o por un tiempo de
inactividad planificado
Plan de contingencia: al final acabará fallando, por tanto hay que tener planes que me
permitan mitigar el impacto del fallo.
