SISTEMAS DISTRIBUIDOS _PRINCIPIOS Y PARADIGMAS

UNIVERSIDAD LAICA ELOY ALFARO DE MANABÍ

FACULTAD DE CIENCI AS INFORMÁTICAS

INTEGRANTES:

BENITEZ CÀRDENAS JOSÈ JUNIOR

BLONDET MIELES DIEGO JAVIER

PINCAY LUCAS MARBELLA LAURY

DOCENTE:
ING. CÉSAR CEDEÑO CEDEÑO, MG.

CURSO:
7 Nivel “A”

FECHA:
MANTA, 28 DE NOVIEMBRE DEL 2017
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

RESUMEN
CAPÌTULO # 7

CONSISTENCIA Y REPLICACIÓN.
La replicación es de gran importancia dentro del mundo de los sistemas distribuidos,
debido a que los datos que se replican ayudan a estar seguro y obtener un buen
rendimiento. El problema principal dentro de esto es que las réplicas sean inconsistentes.
Generalmente los modelos de consistencia para datos compartidos con frecuencia resultan
difíciles de implementar en sistemas distribuidos a gran escala. Además, en muchos casos
es posible utilizar modelos más simples, los cuales también son más fáciles de
implementar. En la mayoría de los casos, las aplicaciones requieren una forma fuerte de
consistencia.
Existen 2 razones principales para replicar datos, siendo éstos la confiabilidad y el
rendimiento. La Replicación y cacheo para el rendimiento se utilizan ampliamente como
técnicas de escalamiento.

La replicación de datos posee problemas de consistencia que no pueden resolverse

eficientemente de una forma general. Sólo si relajamos la consistencia podemos tener la
esperanza de encontrar soluciones eficientes. Por desgracia, tampoco existen reglas
generales para relajar la consistencia: exactamente lo que puede tolerarse depende, en
gran medida, de las aplicaciones.
Hay diferentes formas en que las aplicaciones especifican las inconsistencias que pueden
tolerar. Yu y Vahdat (2002) consideran un método general para diferenciar tres ejes
independientes para definir inconsistencias: desviación en valores numéricos entre
réplicas, desviación en el deterioro entre réplicas, y desviación con respecto al
ordenamiento de operaciones de actualización. Yu y Vahdat se refieren a estas
desviaciones como rangos de consistencia continua.
Medir la inconsistencia en términos de desviaciones numéricas puede utilizarse en
aplicaciones para las que los datos tienen semánticas numéricas. Un ejemplo evidente es
la replicación de registros que contienen precios de acciones. En este caso, una aplicación
puede especificar que dos copias no deben desviarse más de $0.02, lo cual sería una
desviación numérica absoluta.
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

Como alternativa, podría especificarse una desviación numérica relativa, lo cual establece
que dos copias deben diferir no más de, por ejemplo, 0.5%. En ambos casos, veríamos
que si una acción va hacia arriba (y una de las réplicas se actualiza inmediatamente) sin
violar las desviaciones numéricas especificadas, las réplicas aún serían consideradas
como mutuamente consistentes.
La desviación numérica también puede comprenderse en términos del número de
actualizaciones que se han aplicado a una réplica dada, pero que aún no han sido vistas
por otras réplicas. Por ejemplo, un caché web puede no haber visto un lote de operaciones
realizadas por un servidor web.
En este caso, la desviación asociada con el valor también se conoce como su ponderación.
Las desviaciones viejas se relacionan con la última vez que se actualizó una réplica. Para
algunas aplicaciones, es tolerable que una réplica proporcione datos viejos siempre y
cuando no sean demasiado viejos. Por ejemplo, los informes sobre el clima permanecen
a menudo razonablemente precisos durante cierto tiempo, digamos algunas horas. En tales
casos, un servidor principal puede recibir actualizaciones oportunas, pero decidir
propagar las actualizaciones a las réplicas de vez en cuando.
Por último, hay clases de aplicaciones en las que se permite que el ordenamiento de
actualizaciones sea diferente en varias réplicas, siempre que las diferencias sean
limitadas. Una manera de ver estas actualizaciones es que se aplican tentativamente a una
copia local, en espera de un acuerdo global de todas las réplicas. En consecuencia, algunas
actualizaciones necesitarán repetirse y tendrán que aplicarse en un orden diferente antes
de volverse permanentes. Por intuición, el ordenamiento de desviaciones es mucho más
difícil de comprender que las otras dos métricas de consistencia. Más adelante
proporcionaremos ejemplos que clarificarán las cosas.
Consistencia secuencial emplearemos en ella una notación especial en la que trazaremos
las operaciones de un proceso a lo largo de un eje del tiempo. El eje del tiempo siempre
se traza horizontalmente, y aumenta de izquierda a derecha.

MODELO DE CONSISTENCIA CENTRADA AL CLIENTE

Los modelos de consistencia que describimos en la sección anterior ayudan a proporcionar

una vista consistente a lo largo del sistema de un almacén de datos. Una suposición
importante es que procesos concurrentes pueden actualizar simultáneamente el almacén
de datos, y que es necesario proporcionar consistencia ante dicha concurrencia.
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

Consistencia momentánea
Hasta qué punto los procesos en realidad operan de manera concurrente, y hasta qué punto
la consistencia necesita garantizarse, puede variar. Hay muchos ejemplos, en los que la
concurrencia aparece sólo en forma restrictiva.

Lectura Monotónica

Se dice que un dato ofrece consistencia de lecturas monotónicas si y solo si se cumple la

condición de que, si un proceso lee el valor de un ítem de dato x, cualquier operación de
lectura de x por el mismo proceso siempre regresara el mismo valor o un valor más
reciente.
Y garantiza que, si alguno de los procesos ve un valor en determinado tiempo o momento,
nunca vera un valor más viejo de ese valor después de ese momento.
En cuanto a las escrituras, estas deben hacerse en el orden correcto a todas las copas del
almacenamiento de datos.

Lea su Lectura

Es importante que, si se escribe un dato, siempre se vea el valor actualizado no importa

de dónde se esté leyendo, por lo que, para que la consistencia sea de lea sus escrituras se
tiene que cumplir la condición de que si yo escribo algo siempre se tiene que ver ese valor
por las operaciones de lectura sucesivas por el mismo proceso.
Una operación de escritura siempre se completa antes de una operación de lectura
sucesiva del mismo proceso, independiente del lugar.

ADMINISTRACIÓN DE REPLICA

La ubicación del servidor de réplicas tiene que ver con encontrar los mejores lugares para
colocar un servidor que pueda hospedar (parte de) un almacén de datos

Ubicación de servicio de replicas

Existen varias formas de calcular la mejor ubicación de servidores de réplicas, pero todas
se reducen a un problema de optimización en el que se necesita seleccionar la mejor K de
entre N ubicaciones (K < N). Se sabe que estos problemas son de cómputo complejo, y
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

que sólo pueden resolverse mediante la heurística. Qiu y colaboradores (2001) toman la
distancia entre clientes y ubicaciones desde un punto de partida.

Replicas permanentes

Las réplicas permanentes pueden considerarse como el conjunto inicial de réplicas que
constituyen un almacén de datos distribuido. En muchos casos, el número de réplicas
permanentes es pequeño. Por ejemplo, consideremos un sitio web.

Distribución de contenidos
Un punto importante de diseño se refiere a lo que en realidad va a propagarse.
Básicamente existen tres posibilidades:

 Propagar solamente la notificación de una actualización.

 Transferir datos de una copia a otra.
 Propagar la operación de actualización hacia otras copias

PROTOCOLO DE CONSISTENCIA

Un protocolo de consistencia describe la implementación de un modelo específico de

consistencia

CONSISTENCIA CONTINUA
Yu y Vahdat desarrollaron varios protocolos para abordar las tres formas de consistencia.
A continuación, consideraremos brevemente varias soluciones y, por claridad, omitiremos
los detalles.

Límites para la desviación numérica

Nos concentramos en la solución para mantener limitada la desviación numérica. Nos
enfocaremos en escrituras en un solo elemento de datos x.

La idea completa es que cuando el servidor Sk advierte que, Si no ha mantenido el ritmo

de las actualizaciones enviadas a Sk, reenvía las escrituras desde su registro hacia Si. Este
reenvío efectivamente avanza la vista TWk[i,k] que Sk tiene de TW[i,k], haciendo
pequeña la desviación TW[i,k] TWk[i,k]
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

Límites para desviaciones descontinuadas

Un método sencillo es dejar que el servidor Sk mantenga un reloj vectorial de tiempo real
RVCk, donde RVCk[i].

T(i) significa que Sk ha visto todas las escrituras enviadas a Si al tiempo T(i). En este
caso, suponemos que cada escritura enviada es registrada por su servidor origen, y que
T(i) denota el tiempo local en Si. Si los relojes entre los servidores de réplicas están
aproximadamente sincronizados, entonces un protocolo aceptable para limitar la
discontinuidad sería el siguiente.

Límites para desviaciones de ordenamiento

La desviación de ordenamiento se limita especificando la longitud máxima de la cola de
escrituras tentativas

PROTOCOLOS BASADOS EN PRIMARIAS

Protocolos de escritura remota
El protocolo más sencillo basado en primarias que soporta la replicación es aquél en el
que todas las operaciones de escritura necesitan remitirse a un solo servidor fijo. Tales
esquemas también se conocen como protocolos primarios de respaldo (Budhiraja y cols.,
1993).

Protocolos de escritura local

Este protocolo primario de respaldo de escritura local también puede aplicarse a
computadoras móviles que son capaces de operar desconectadas. Antes de desconectarla,
la computadora móvil se vuelve el servidor primario para cada elemento de datos que
espera actualizar.

PROTOCOLOS DE ESCRITURA REPLICADO

Replicación activa

Cada réplica tiene un proceso asociado que realiza operaciones de actualización.

Un problema con la replicación activa es que las operaciones deben realizarse en el mismo
orden en cualquier parte.
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

CAPÌTULO # 8

TOLERANCIA A FALLAS

Una característica sobresaliente de los sistemas distribuidos que los distingue de los
sistemas de una sola máquina es la noción de falla parcial. Una falla parcial puede
acontecer cuando falla un componente. En un sistema no distribuido, una falla a menudo
es total en el sentido de que afecta a todos los componentes y fácilmente puede echar
abajo al sistema.
En este capítulo, examinamos más a fondo las técnicas apropiadas para hacer que los
sistemas distribuidos toleren las fallas. Después de proporcionar algunas bases generales
sobre tolerancia a las fallas, daremos un vistazo a la atenuación del proceso y a la
multitransmisión confiable. La atenuación del proceso incorpora técnicas mediante las
cuales uno o más procesos pueden fallar sin perturbar seriamente el resto del sistema.
Relacionada con este tema está la multitransmisión, gracias a la cual se garantiza la
transmisión exitosa de un mensaje hacia un conjunto de procesos. La multitransmisión
confiable a menudo es necesaria para mantener sincronizado el proceso.

Introducción a la tolerancia a las fallas

La tolerancia a las fallas se ha investigado mucho en la ciencia de la computación. En esta

sección, primero se presentan los conceptos básicos relacionados con las fallas de
procesamiento, seguidos por un análisis de modelos de fallas.

Conceptos básicos

Para entender el rol de la tolerancia a fallas en los sistemas distribuidos. Ser tolerante a
las fallas está fuertemente relacionado con lo que se llama sistemas fiables. Comprende
varios requerimientos útiles para los sistemas distribuidos incluidos los siguientes:

1. Disponibilidad
2. Confiabilidad
3. Seguridad
4. Mantenimiento
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

Modelos de falla

Un sistema que falla no proporciona adecuadamente los servicios para los que fue
diseñado. Si se considera un sistema distribuido como un conjunto de servidores que se
comunican entre sí y con sus clientes, no proporcionar adecuadamente los servicios
significa que los servidores, los canales de comunicación, o posiblemente ambos, no están
haciendo lo que se supone deben hacer. Sin embargo, un servidor que funciona mal no
siempre es la falla buscada.
Para tener una mejor idea de qué tan seria es en realidad una falla, se han desarrollado
varios esquemas de clasificación. Uno de éstos se muestra en la figura 8-1, y está basado
en esquemas descritos en Cristian (1991) y Hadzilacos y Toueg (1993).

Disfrazado de fallas por redundancia

La técnica clave para disfrazar las fallas es utilizar redundancia. Tres clases son posibles:
redundancia de información, redundancia de tiempo, y redundancia física [vea también
Johnson (1995)]. Con redundancia de información, se agregan bits adicionales para
recuperar los bits mutilados. Por ejemplo, se puede agregar un código Hamming a los
datos transmitidos para recuperarlos del ruido presente en la línea de transmisión. Con
redundancia de tiempo, se realiza una acción, y luego, si es necesario, se vuelve a realizar.
Las transacciones (vea el capítulo 1) utilizan este método. Si se aborta una transacción,
puede rehacerse sin ningún perjuicio. La redundancia de tiempo resulta especialmente útil
cuando las fallas son transitorias e intermitentes. Con redundancia física, se agrega equipo
o procesos adicionales para que el sistema en su conjunto tolere la pérdida o el mal
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

funcionamiento de algunos componentes. La redundancia física puede realizarse entonces

en el hardware o el software. Por ejemplo, se pueden agregar procesos adicionales al
sistema de modo que si algunos se congelan, el sistema pueda seguir funcionando
correctamente. En otros términos, al replicar procesos se logra un alto grado de tolerancia
a fallas.
Consideremos, por ejemplo, el circuito de la figura 8-2(a). Las señales pasan a través de
los dispositivos A, B y C, en secuencia. Si un dispositivo falla, el resultado final
probablemente será incorrecto.

Atenuación de un proceso

En las páginas siguientes, consideramos temas de diseño generales de grupos de procesos

y analizamos lo que es realmente un grupo tolerante a fallas. También, vemos cómo llegar
a un acuerdo dentro de un grupo de procesos cuando no se confía en que uno o más de
sus miembros den respuestas correctas.

Temas de diseño

La forma clave de afrontar la tolerancia a un proceso defectuoso es organizar varios

procesos idénticos en un grupo.
Los grupos de procesos pueden ser dinámicos. Se pueden crear grupos nuevos y destruir
los viejos. Un proceso puede unirse a un grupo o abandonarlo durante la operación del
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

sistema. Un proceso puede ser miembro de varios grupos a la vez. El propósito de la

introducción de grupos es permitir que los procesos se ocupen de los conjuntos de
procesos como una sola abstracción.

Enmascaramiento de fallas y replicación

Tener un grupo de procesos idénticos permite disfrazar uno o más procesos defectuosos
presentes en dicho grupo. La replicación basada en un protocolo primario, en el caso de
tolerancia a fallas, generalmente aparece en la forma de un protocolo de respaldo
primario.

Acuerdo en sistemas defectuosos

1. Sistemas síncronos contra sistemas asíncronos. Un sistema es síncrono si, y sólo

si, se sabe que los procesos operan por pasos. Formalmente, esto significa que
deberá haber una constante c _ 1, de modo que si cualquier proceso tomó c _ 1
pasos, todos los otros procesos habrán tomado por lo menos 1 paso. Se dice que
un sistema no síncrono es asíncrono.
2. El retraso de la comunicación está o no limitado. El retraso está limitado si, y sólo
si, se sabe que cada mensaje es entregado con un tiempo globalmente máximo y
predeterminado.
3. La entrega de mensajes se hace o no en orden. En otros términos, es posible
distinguir una situación en la que los mensajes del mismo remitente se entregan
en el orden en que fueron enviados de una situación en que no se tienen tales
garantías.
4. Los mensajes se transmiten mediante unitransmisión o multitransmisión.

Detección de fallas

La detección de fallas es una de las piedras angulares de la tolerancia a fallas en sistemas

distribuidos. Existe una enorme cantidad de trabajo teórico sobre detectores de fallas. A
lo que se reduce es a la utilización de un mecanismo de tiempo fuera para verificar si un
proceso ha fallado. En situaciones reales, existen dos problemas importantes con esta
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

forma de proceder. En primer lugar, debido a las redes no confiables, afirmar simplemente
que un proceso ha fallado porque no responde a un mensaje ping puede ser erróneo. En
otros términos, es bastante fácil generar falsos positivos. Si un falso positivo tiene el
efecto de que un proceso perfectamente saludable es eliminado de una lista de membresía,
entonces claramente algo se está haciendo mal.

Comunicación confiable entre cliente y servidor

En muchos casos, la tolerancia a fallas en sistemas distribuidos se concentra en procesos

defectuosos.
Sin embargo también se tienen que considerar las fallas de comunicación. Los modelos
de fallas analizados previamente aquí también son válidos en su mayoría para canales de
comunicación. En particular, un canal de comunicación puede presentar fallas por
congelación, omisión, temporización, y arbitrarias.
Se tiene algunas observaciones como:

1. Comunicación punto a punto

2. Semántica RPC en presencia de fallas
3. El cliente no puede localizar el servidor
4. Pérdida de mensajes de solicitud
5. Congelación del servidor
6. Pérdida de mensajes de respuesta
7. Congelaciones de cliente
Realización distribuida

El problema de multitransmisión atómica analizado en la sección previa es ejemplo de un

problema todavía más general, conocido como realización distribuida. El problema de
realización distribuida implica lograr que una operación sea realizada por cada miembro
de un grupo o por ninguno en absoluto. En el caso de multitransmisión confiable, la
operación es la entrega de un mensaje. Con transacciones distribuidas, la operación puede
ser la realización de una transacción en un solo sitio que interviene en la transacción.
Otros ejemplos de realización distribuida y cómo puede ser resuelta se analizan en
Tanisch (2000).
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

La realización distribuida a menudo se establece por medio de un coordinador. En un

esquema simple, este coordinador comunica a todos los demás procesos involucrados,
llamados participantes, si deben realizar o no (localmente) la operación de que se trate.
Este esquema se refiere a un protocolo de realización monofásico, y tiene la desventaja
evidente de que si uno de los participantes en efecto no puede realizar la operación, no
hay forma de comunicárselo al coordinador. Por ejemplo, en el caso de transacciones
distribuidas, no es posible implementar una realización local porque violaría las
restricciones de control de concurrencia.

Recuperación

La recuperación de errores es fundamental para la tolerancia a fallas. Recordemos que un

error es esa parte de un sistema que puede conducir a una falla. La idea integral sobre
recuperación de errores es reemplazar un estado erróneo con un estado libre de error.
Esencialmente, existen dos formas de recuperación de errores. En la recuperación hacia
atrás, lo principal es hacer que el sistema regrese de su estado actual erróneo a su estado
previamente correcto. Para lograrlo, será necesario registrar el estado del sistema de vez
en cuando y, cuando las cosas vayan mal, restaurar el estado registrado.
Cada vez que se registra (una parte de) el estado actual del sistema, se dice que se marca
un punto de control.
Otra forma de recuperación de errores es la recuperación hacia adelante. En este caso,
cuando el sistema ha entrado a un estado erróneo, en lugar de regresarlo a un estado de
punto de control previo, se intenta llevarlo a un nuevo estado correcto a partir del cual se
pueda continuar ejecutando. El problema principal con los mecanismos de recuperación
de errores hacia adelante es que se debe saber de antemano qué errores pueden ocurrir.
Sólo en ese caso es posible corregir los errores y trasladarse a un nuevo estado. La
distinción entre la recuperación de errores hacia atrás y hacia adelante se explica con
facilidad cuando consideramos la implementación de comunicación confiable.

Almacenamiento estable

Para recuperarse a un estado previo, es necesario que la información requerida para

habilitar la recuperación sea guardada con seguridad. Seguridad en este contexto significa
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

que la recuperación sobreviva a congelaciones de proceso y fallas de sitio, pero quizá

también a varias fallas de medios de almacenamiento. El almacenamiento estable
desempeña un rol muy importante cuando se trata de recuperación en sistemas
distribuidos. Aquí lo analizamos brevemente.
El almacenamiento se presenta en tres categorías. Primero, existe una memoria RAM
ordinaria que se borra cuando falla la corriente o una máquina se congela. En segundo
lugar tenemos un almacenamiento en disco, el cual sobrevive a fallas de la CPU pero
también se puede perder cuando ocurren fallas de cabeza de disco.

Si bien sabemos la tolerancia a fallas es un tema importante en el diseño de sistemas

distribuidos. La tolerancia a fallas se define como la característica mediante la cual un
sistema puede ocultar la ocurrencia y la reparación de fallas. En otros términos, un sistema
es tolerante a fallas si puede continuar operando en presencia de éstas.
Existen varios tipos de fallas. Una falla de congelación ocurre cuando un proceso
simplemente se detiene. Una falla por omisión ocurre cuando un proceso no responde a
las solicitudes entrantes.
Cuando un proceso responde demasiado rápido o demasiado tarde a una solicitud, se dice
que exhibe una falla de temporización. Responder a una solicitud entrante, pero de manera
equivocada, es un ejemplo de falla de respuesta. Las fallas más difíciles de manejar,
llamadas fallas arbitrarias o bizantinas, son aquellas mediante las cuales un proceso
exhibe cualquier clase de falla. La redundancia es la técnica fundamental requerida para
lograr la tolerancia a fallas. Cuando se aplica a procesos, la noción de grupos de procesos
se vuelve importante. Un grupo de procesos se compone de varios procesos que cooperan
estrechamente para proporcionar un servicio. En grupos de procesos tolerantes a fallas,
uno o más procesos pueden fallar sin afectar la disponibilidad del servicio que ofrece el
grupo. A menudo, es necesario que la comunicación dentro del grupo sea altamente
confiable y que se adhiera a propiedades de atomicidad y ordenamiento estrictas para
lograr la tolerancia a fallas.
La comunicación de grupo confiable, también llamada multitransmisión confiable, se
presenta en formas diferentes. En tanto los grupos sean relativamente pequeños, la
implementación de la confiabilidad es factible. Sin embargo, cuando grupos muy grandes
tienen que ser soportados, la escalabilidad de la multitransmisión confiable se vuelve
problemática. El tema clave al lograr la escalabilidad es reducir el número de mensajes
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

de retroalimentación mediante los cuales los receptores informan sobre la recepción (no)
exitosa de un mensaje multitransmitido. Las cosas empeoran cuando se tiene que
proporcionar atomicidad. En protocolos de multitransmisión atómica, es esencial que
cada miembro del grupo tenga la misma visión con respecto a qué miembros fue
entregado un mensaje multitransmitido. La multitransmisión atómica puede ser formulada
con precisión en función de un modelo de ejecución síncrono virtual. En esencia, este
modelo presenta límites entre cuáles miembros del grupo no cambian y qué mensajes son
transmitidos confiablemente. Un mensaje nunca puede cruzar un límite. Los cambios de
membresía al grupo son un ejemplo en el que cada proceso tiene que estar de acuerdo con
la misma lista de miembros. Semejante acuerdo puede alcanzarse por medio de protocolos
de realización, de los cuales el de dos fases es el más aplicado. En un protocolo de
realización bifásico, un coordinador primero investiga si todos los procesos están de
acuerdo en realizar la misma operación (es decir, si todos están de acuerdo en realizarla),
y en una segunda ronda multitransmite el resultado de dicha encuesta. Se utiliza un
protocolo de realización trifásico para ocuparse de la congelación del coordinador sin
tener que bloquear todos los procesos para llegar a un acuerdo hasta que el coordinador
se recupere. En sistemas tolerantes a fallas, la recuperación se logra invariablemente
marcando con puntos de control el estado del sistema en forma regular. La marcación de
puntos de control es completamente distribuida. Desafortunadamente, la toma de un punto
de control es una operación cara. Para mejorar el desempeño, muchos sistemas
distribuidos combinan la marcación de puntos de control con el registro de mensajes.
Registrando la comunicación entre los procesos, llega a ser posible repetir la ejecución
del sistema después de ocurrida una congelación.
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

CAPÌTULO # 9

El último principio de sistemas distribuidos que se analiza es el de seguridad. La seguridad

de ningún modo es el punto menos importante. Sin embargo, se podría argumentar que es
uno de los más difíciles, ya que la seguridad tiene que estar presente en todo el sistema.
Una sola falla de diseño con respecto a la seguridad puede hacer que todas las medidas
de seguridad sean inútiles. En este capítulo, prestamos atención especial a los diversos
mecanismos incorporados en general en los sistemas distribuidos para dar soporte a la
seguridad.
En un sistema de computadora, la seguridad está fuertemente relacionada con la noción
de confiabilidad. Informalmente, un sistema de computadora confiable es uno en el que
justificadamente confiamos nos suministrará sus servicios (Laprie, 1995).
Otra forma de considerar la seguridad en los sistemas de computadora es como un intento
de proteger los servicios y datos que ofrece contra amenazas de seguridad. Existen cuatro
tipos de amenazas de seguridad a considerar (Pfleeger, 2003):
1. Intercepción
2. Interrupción
3. Modificación
4. Fabricación

Las entidades incluyen usuarios, servicios, datos, máquinas, etc. Un vez delineada una
política de seguridad, es posible concentrarse en el mecanismo de seguridad mediante
el cual pueda ser aplicada. Estos mecanismos de seguridad importantes son:

1. Cifrado
2. Autenticación
3. Autorización
4. Auditoría
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

Podemos observar el siguiente ejemplo:

Temas de diseño
Un sistema distribuido, o cualquier sistema de computadora, deben proporcionar servicios
de seguridad mediante los cuales pueda ser implementada una amplia gama de políticas
de seguridad.
Existen varios temas de diseño importantes que deben ser tomados en cuenta cuando se
implementen servicios de seguridad para propósitos generales. En las páginas siguientes
analizamos tres de estos temas: enfoque del control, organización en capas de los
mecanismos de seguridad, y simplicidad.
Enfoque del control
Cuando se considera la protección de una aplicación (posiblemente distribuida), existen
básicamente tres métodos diferentes que pueden ser seguidos, como se muestra en la
figura 9-2. El primer método consiste en concentrarse directamente en la protección de
los datos asociados con la aplicación. Directamente significa que independientemente de
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

las diversas operaciones que posiblemente pueden ser realizadas en un rubro de datos, el
interés principal es garantizar su integridad.
Observemos la figura:

Integridad y confidencialidad del mensaje

Además de autenticación, un canal seguro también debe proporcionar garantías en cuanto

a integridad y confidencialidad del mensaje. Integridad del mensaje significa que los
mensajes están protegidos contra modificación subrepticia; la confidencialidad asegura
que los mensajes no pueden ser interceptados y leídos por fisgones. La confidencialidad
es fácil de establecer simplemente con cifrar un mensaje antes de enviarlo. El cifrado
puede tener lugar o mediante una clave secreta compartida con el destinatario o,
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

alternativamente, con la clave pública del destinatario. Sin embargo, la protección de un

mensaje contra modificaciones es un poco más complicada, como se verá a continuación.

Control de acceso

En el modelo cliente-servidor, el cual se ha utilizado hasta ahora, una vez que un cliente
y un servidor establecen un canal seguro, el cliente puede emitir peticiones que deben ser
ejecutadas por el servidor. Las peticiones implican realizar operaciones en recursos
controlados por el servidor. Una situación general es la de un servidor de objetos que tiene
varios objetos bajo su control. Una petición de un cliente implica, por lo general, invocar
un método de un objeto específico. Tal petición puede ser realizada sólo si el cliente tiene
derechos de acceso suficientes para conseguir dicha invocación.

La seguridad desempeña un rol extremadamente importante en los sistemas distribuidos.

Un sistema distribuido deberá proporcionar mecanismos que permitan aplicar varias
políticas de seguridad diferentes. El desarrollo y la aplicación apropiada de dichos
mecanismos generalmente hacen que la seguridad sea un difícil ejercicio de ingeniería.
Se distinguen tres temas importantes. El primero es que un sistema distribuido deberá
ofrecer los medios necesarios para establecer canales seguros entre procesos. Un canal
seguro, en principio, proporciona los medios para autenticar manualmente las partes que
se están comunicando y para proteger los mensajes contra modificaciones durante su
transmisión. Un canal seguro, en general, proporciona confidencialidad de tal forma que
nadie más que la partes en comunicación puedan leer los mensajes transmitidos por el
canal.
Un tema de diseño importante es si utilizar sólo un criptosistema simétrico (basado en
claves secretas compartidas) o combinarlo con un sistema de clave pública. La práctica
actual utiliza criptografía de clave pública para distribuir claves secretas compartidas de
corta duración. Las últimas se conocen como claves de sesión.
El segundo tema en sistemas distribuidos seguros es el control de acceso, o autenticación.
La autorización se ocupa de proteger los recursos de tal forma que sólo aquellos procesos
que tengan los derechos de acceso apropiados puedan acceder a ellos y utilizarlos. El
control de acceso siempre ocurre después de que un proceso ha sido autenticado.
 SISTEMAS DISTRIBUIDOS_PRINCIPIOS Y PARADIGMAS

Relacionado con el control de acceso está evitar la negación de servicio, lo cual se torna
en un problema difícil en sistemas que son accesibles a través de internet. Existen dos
formas de implementar el control de acceso. Primero, cada recurso puede llevar una lista
de control de acceso que incluya con exactitud los derechos de acceso de cada usuario o
proceso. Alternativamente, un proceso puede portar un certificado que establezca con
precisión cuáles son sus derechos para un conjunto particular de recursos. El beneficio
principal de utilizar certificados es que un proceso puede transferir con facilidad su boleto
a otro proceso, es decir, delegar sus derechos de acceso. Los certificados, sin embargo,
tienen la desventaja de que con frecuencia son difíciles de revocar.
Se requiere atención especial con el control de acceso en el caso de un código móvil.
Además, proteger un código móvil contra un servidor malicioso, en general, es más
importante que protegerlo contra un código móvil malicioso. Se han hecho varias
proposiciones, de las cuales la caja de arena es actualmente la más aplicada. Sin embargo,
las cajas de arena son algo restrictivas y por ello se han ideado métodos más flexibles
basados en dominios de protección verdadera.
El tercer tema en los sistemas distribuidos seguros tiene que ver con administración.
Existen esencialmente dos subtemas importantes: la administración de claves y la
administración de la autorización.
La administración de claves incluye la distribución de claves criptográficas, para lo cual
los certificados emitidos por terceras partes confiables desempeñan un rol importante.
Con respecto a la administración de la autorización, también son importantes los
certificados de atributo y la delegación.