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