Confiabilidad en Sistemas Distribuidos

Sistemas de Computación
CONFIABILIDAD en SD
recuperación que alivien el efecto de dichos errores
y que permitan aumentar el grado de confiabilidad y
seguridad del sistema.
Referencias:
George A. Champine; Distributed Computer Systems, impact on management, design and analysis.
North Holland, 1980. Capítulo 13.
I.- INTRODUCCIÓN
Las tendencias comunes en el diseño de sistemas
tienden hacia la distribución de operaciones, datos y
procesamiento. No solamente hacen que más
gente tenga acceso a los recursos internos del
computador, sino que, en la arquitectura distribuida,
se ha incrementado el riesgo de penetración externa
a través de las líneas de comunicación. Uno de los
objetivos claves de los sistemas distribuidos es
proporcionar fácil acceso a los datos. A menos que
se tomen medidas en contrario, los sistemas distribuidos ofrecen fácil acceso autorizado y no autorizado. La naturaleza diversa de las aplicaciones comunes y la sensibilidad de los datos que están
siendo almacenados, han incrementado ampliamente las recompensas para el "timador" del computador y el robo de información en él. Así, deben
incorporarse nuevas medidas, las cuales suplementarán o suplantarán los controles existentes.
En las décadas pasadas no se tuvo la necesidad de
realizar un cambio drástico en la importancia que
tiene el manejo de un sistema de información totalmente integrado. El computador ha tenido gran
importancia esencialmente en organizaciones donde
las fallas en sus funciones conducirían muy rápidamente a la detención de las operaciones. La pérdida de información que se halla almacenada en el
computador por periodos prolongados, destruirá
esencialmente a toda organización. Por esta razón,
el tópico de confiabilidad es de gran importancia en
sistemas distribuidos.
El concepto de "failsoft" o software con fallas (fallas
menores) se ha introducido en forma cualitativa. Un
sistema con fallas menores es aquel, que a pesar
de una o dos fallas, puede continuar en operación,
posiblemente en un modo más degradado.
También se considera como confiable (como meta)
el hecho de que el usuario no necesite tomar precauciones contra posibles fallas.
A pesar de que se han empleado normas de seguridad para incrementar la confiabilidad de un sistema distribuido, el sistema está afecto a errores.
Cada vez que ocurre un error, podría propagarse en
una forma impredecible a través del sistema. Por lo
tanto, se deben aplicar diversas técnicas de
1/2000
2 TRANSFERENCIA DE DATOS
El modelo básico de transferencia de datos a través
de un protocolo de transporte, es un flujo de datos
proporcionados por un proceso fuente, los cuales
son empaquetados por el protocolo fuente de
transporte, enviados a través de un medio de
transmisión, y reconstituidos a través de un flujo de
datos para el proceso destino.
Podemos llamar a los elementos del protocolo que
se dedican a enviar una "disciplina de envío", y los
que reciben, una "disciplina de recibo", naturalmente una conexión full dúplex tiene disciplina de
envío y recibo a cada lado, y para mayor eficiencia,
el reconocimiento de información puede ser llevado
junto con los datos en la dirección contraria, sin
embargo, para propósitos de análisis, las dos
direcciones de flujo de información pueden ser
consideradas separadas lógicamente.
Metas de ejecución detalladas pueden ser formuladas en términos de un flujo de paquetes submitidos
o liberados. Esto concierne la posibilidad para deterioros, pérdidas, duplicación, o liberación fuera de
orden de paquetes por el medio de transmisión.
La disciplina de envío mantiene una variable llamada "número de secuencia próximo (NSN)". Cada paquete submitido tiene un NSN asociado y en
que el NSN es avanzado a su sucesor.
En el reconocimiento de paquetes a la llegada, los
ACKs son chequeados por errores y deterioro, y algunos son descartados. Los ACKs para paquetes
descartados son ignorados.
Cuando una referencia ACK al número de un paquete pendiente es recibido, el paquete pendiente
es descartado. Si un ACK no es recibido para un
paquete pendiente en un intervalo de transmisión,
el paquete pendiente es retransmitido y el reloj es
reinicializado.
La disciplina de recibo mantiene una variable llamada "número de secuencia esperado" (ESN).
Cada paquete recibido es chequeado por errores y
descartado si está deteriorado. Si no está deteriorado, el número de secuencias del paquete (PSN)
es comparado con el ESN y la acción es tomada
como sigue:
pág.: 1 de 3
Sistemas Distribuidos
Confiabilidad
-
Si es menor, transmite un ACK que referencia a
un PSN y descarta el paquete como una duplicación.
reconocidos, podrían llevar ya sea a pérdida o duplicación de la información.
-
Si es igual, transmite un ACK, libera el paquete al
proceso, y avanza el ESN a sus sucesor.
3. CONFIABILIDAD EN SISTEMAS DISTRIBUIDOS NO REDUNDANTES
-
Si es mayor, descarta el paquete como fuera de
orden.
Para calcular la confiabilidad de cualquier sistema
no redundante, es necesario definir tres términos y
dos relaciones. Los tres términos son:
Las definiciones del protocolo anterior asumen que
todos los deterioros a paquetes o reconocimientos
pueden ser detectados. También se asume que el
protocolo es inicializado apropiadamente (es decir,
la conexión es establecida). Esto significa que el
NSN en la disciplina de envío es igual al ESN en la
disciplina de recibo en el otro lado de la conexión y
que ningún paquete de datos ha sido enviado.
Además se supone un espacio infinito de los números de secuencia.
Los flujos de control sujetos y el posible uso de reconocimientos negativos son también ignorados,
puesto que ellos pueden afectar la eficiencia pero no
la correcta operación del protocolo.
Con estos supuestos se pueden ver que las metas
ejecutables están reunidas, considerando cada posible tipo de error:
- duplicación
- deterioro
- pérdida
- secuenciación
En realidad, los números de secuencias deben ser
finitos en longitud y de aquí que eventualmente envuelven a valores previamente usados. Si los paquetes pueden persistir arbitrariamente en un tiempo largo en el medio de transmisión, los paquetes
antiguos pueden llegar a la disciplina de recibo y ser
aceptados en lugar de paquetes nuevos con los
mismos números de secuencias. Los reconocimientos pueden también ser retrasados, provocando que la disciplina de envío piense que un paquete
ha sido transmitido exitosamente, cuando en realidad no lo ha sido.
tiempo medio entre fallas (MTBF)
tiempo medio para reparar (MTTR)
disponibilidad.
Tiempo medio entre fallas y tiempo medio para reparar son lo que el nombre implica y son aplicados
a cualquier componente del sistema. Tiempo medio para reparar, en el caso de un sistema, incluye
la recuperación de la base de datos y el tiempo
para reejecución. Disponibilidad es la fracción de
tiempo en que cualquier componente se encuentra
operacional, y está definido por la siguiente relación:
disponibilidad:
A
MTBF
MTBF MTTR
Disponibilidad puede ser definida a nivel de sistema
o subsistema usando la misma relación, donde
MTBF viene a ser el tiempo para cualquier falla.
El tiempo medio típico para reparar es del orden de
30 a 60 minutos para sistemas no-redundantes, si
el personal y los repuestos están en el sitio adecuado.
La disponibilidad de un subsistema o sistema
puede ser calculada desde las disponibilidades de
sus componentes. Si todos los componentes de un
sistema deben estar operativos (esto es, no redundante) para que el sistema este operacional, la disponibilidad A del sistema es producto de las disponibilidades de cada uno de sus componentes Ai
como sigue:
A(sistema) = p (Ai)
Consecuencia de los fracasos:
Una base de datos particionada es un ejemplo de
sistema no redundante.
El anterior análisis asume que las disciplinas de envío y recibo llegan a operar correctamente sin pérdida de memoria en toda la duración de la conexión.
También es importante considerar las consecuencias cuando un lado de la conexión fracasa
con pérdida de memoria, como podría ocurrir en una
caída del hosts, bajo estas circunstancias, los
paquetes que han sido transmitidos pero todavía no
Para tener un sistema distribuido no-redundante
confiable, cada componente del sistema debe ser
confiable.
Si un nodo tiene 10 componentes
(discos, procesadores, memorias), cada uno con
una confiabilidad de 0.99, la disponibilidad completa
del nodo es 0.9 (90%) dado por:
A(nodo) = (0.99)10 ~ 0.9
Sistemas Distribuidos
Si hay 10 nodos en un sistema no-redundante, cada
uno con una disponibilidad de 0.9, la disponibilidad
del sistema es 34,8%, dado por:
A(sistema) = (0.9)10 = 0.348
Así este sistema sería casi siempre inútil. Un sistema batch debería tener alrededor de 95% de disponibilidad para ser útil, y un sistema interactivo
debería tener un 98% de disponibilidad. Así, la
disponibilidad de los nodos debería ser muy alta
(alrededor de 0.995) y la disponibilidad de los componentes en un nodo debe ser al menos del orden
de 0.999 de confiabilidad.
4 CONFIABILIDAD EN SISTEMAS DISTRIBUIDOS REDUNDANTES
Un sistema distribuido redundante es un sistema el
cual tiene dos o más componentes de cada tipo. La
redundancia permite que un sistema sea failsoft.
Las técnicas de redundancia y failsoft han sido
usadas por la industria militar y aerospacial por
muchos años para alcanzar una alta confiabilidad.
Una base de datos replicada es un ejemplo de sistema distribuido redundante.
La confiabilidad A de un sistema redundante, un
componente que debe ser operacional para que el
sistema sea operacional, está dado por:
A(sistema) = 1 - p (1 - Ai)
donde Ai es la disponibilidad del i-esimo componente.
Si el sistema está compuesto de dos nodos, cada
uno de los cuales tiene una disponibilidad de 0.99
(para usar nuestro ejemplo previo), la confiabilidad
del sistema es:
A(sistema) = 1 - (1-0.99)2 = 0.9999
Así un sistema redundante de dos nodos tiene una
disponibilidad muy alta, comparado con un sistema
con un sólo nodo con la misma disponibilidad.
Sin embargo, a pesar que la disponibilidad puede
ser muy alta con un sistema redundante, la mantención puede ser un problema. Si el tiempo medio
entre fallas para un nodo es 1.000 horas, entonces
un sistema de 20 nodos, requiere mantención cada
50 horas en algún nodo, para mantener la disponibilidad muy alta. Un nivel alto de mantención puede
ser muy caro.
Confiabilidad