Beruflich Dokumente
Kultur Dokumente
INTEGRANTES:
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.
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.
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
Lea su Lectura
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
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:
PROTOCOLO 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.
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.
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.
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).
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
Atenuación de un proceso
Temas de diseño
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.
Detección de fallas
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.
Recuperación
Almacenamiento estable
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
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
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:
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.
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.