Sistemas Distribuidos
Chanona Leyva José Luis
11/01/2014
INDICE UNIDAD I ..................................................................................................................................................... 0
1
ARQUITECTURA ARQUITECTURA DE UN SISTEMA SISTEMA DISTRIBUIDO .................................................................... 1 1.2
CARACTERÍSTICAS DE UN SISTEMA DISTRIBUIDO. ..................................................... 2
1.2.1
COMPARTICIÓN DE RECURSOS. ................................................................................ 2
1.2.2
APERTURA. APERTURA. ........................................................................................................................ 3
1.2.3
CONCURRENCIA. ............................................................................................................. 3
1.2.4
ESCALABILIDAD. ..............................................................................................................
1.2.5
TOLERANCIA A FALLOS. ................................................................................................ 6
1.2.6
TRANSPARENCIA. ............................................................................................................
4
6
1.3
MODELOS ARQUITECTÓNICOS. .......................................................................................... 7
1.4
MODELOS FUNDAMENTALES. ............................................................................................. 8
1.5
RECURSOS DE COMUNICACIÓN. .....................................................................................
12
1.5.1
PROTOCOLOS TCP/IP. .................................................................................................
1.5.2
SERVICIOS Y PUERTOS. .............................................................................................. 15
1.5.3
PROCESOS Y DEMONIOS. ..........................................................................................
13
18
UNIDAD II .................................................................................................................................................... 1
2
PROCEDIMIENTO DISTRIBUIDO .................................................................................................. 1 2.1
INTRODUCCIÓN A LOS SISTEMAS DE MULTIPROCESAMIENTO. .................. ............ 1
2.2
CLASIFICACIÓN DE LOS SISTEMAS DE MULTIPROCESAMIENTO. ........................... 2
2.2.1
FUERTEMENTE ACOPLADOS. ...................................................................................... 2
2.2.2
DÉBILMENTE ACOPLADOS. .......................................................................................... 2
2.2.3
ESPECIALIZADOS. ...........................................................................................................
2
SISTEMAS DE CLUSTERS. ....................................................................................................
2
2.3
2.3.1
MULTIPROCESAMIENTO DEDICAD Y COPARTIDO. ............................................... 4
2.4
PROTOCOLOS DE COMUNICACIÓN. .................................................................................. 5
2.5
PASO DE MENSAJES. .............................................................................................................
2.6
OBJETOS REMOTOS ............................................................................................................... 6
2.7
PROCEDIMIENTOS REMOTOS. ............................................................................................ 7
UNIDAD III...................................................................................................................................................
3
6
1
ALMACENAMIENDO ALMACENAMIENDO DE DATOS DISTRIBUIDOS DISTRIBUIDOS ...................................................................... 1
3.1
ALMACENAMIENTO ALMACENAMIENTO DE ALTA DISPONIBILIDAD DISPONIBILIDAD.. ............................................................. 1
3.2
SERVICIOS LOCALES DE ALTA DISPONIBILIDAD. ......................................................... 3
3.2.1
ARREGLOS ARREGLOS DE DISCO. DISCO. ................................................................................................... 4
3.2.2
MANEJO DE TRANSACCIONES. ................................................................................... 5
3.3
SERVICIOS DISTRIBUIDOS DE ALTA DISPONIBILIDAD. ............................................... 7
3.3.1
SERVICIOS DE ALMACÉN DE ARCHIVOS. ................................................................ 7
3.4
SERVICIOS DE DIRECTORIOS Y BÚSQUEDA. ................................................................. 9
3.5
SERVICIOS DE ARCHIVOS EN RED. ................................................................................. 10
3.6
REPLICACIÓN. ........................................................................................................................
11
UNIDAD IV .................................................................................................................................................. 1
4
CONTROL DE CONCURRENCIA ................................................................................................... 1 4.1
CONCURRENCIA. ..................................................................................................................... 1
4.2
CONTENCIÓN Y CONTROL DE LA CONCURRENCIA. .................................................... 1
4.3
TRANSACCIONES. ...................................................................................................................
3
4.4
TRANSACCIONES ANIDADAS. ............................................................................................
5
4.5
BLOQUEOS. ...............................................................................................................................
6
4.6
MARCAS DE TIEMPO. .............................................................................................................
7
UNIDAD V ................................................................................................................................................... 1
5
CONTROL DE ERRORES................................................................................................................ 5.1
1
CASOS DE FALLAS. ................................................................................................................. 1
5.1.1
FALLAS LOCALES. ...........................................................................................................
1
5.1.2
FALLA DE SITIO. ...............................................................................................................
1
5.1.3
FALLAS DEL CANAL DE COMUNICACIÓN. ................................................................ 2
5.2
PROTOCOLOS DE RECUPERACIÓN. .................................................................................
5.3
PROTOCOLOS DE RECUPERACIÓN DISTRIBUIDOS. .................................................... 3
2
UNIDAD VI .................................................................................................................................................. 1
6
ESCENARIOS DE APLICACIÓN ....................................................................................................
1
6.1
CORBA. .......................................................................................................................................
6.2
SISTEMA OPERATIVO MATCH. ............................................................................................
6.3
RMI (Java Remote Method Invocation). ................................................................................. 4
6.4
INFORMÁTICA DISTRIBUIDA. ................................................................................................ 5
1 2
UNIDAD I
1
ARQUITECTURA DE UN SISTEMA DISTRIBUIDO
1.1
INTRODUCCIÓN.
Un sistema distribuido se define como una colección de computadores autónomos conectados por una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una única entidad capaz de proporcionar facilidades de computación. [Colouris 1994] El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de alta velocidad a principios de 1970. Más recientemente, la disponibilidad de computadoras personales de altas prestaciones, estaciones de trabajo y ordenadores servidores ha resultado en un mayor desplazamiento hacia los sistemas distribuidos en detrimento de los ordenadores centralizados multiusuario. Esta tendencia se ha acelerado por el desarrollo de software para sistemas distribuidos, diseñado para soportar el desarrollo de aplicaciones distribuidas. Este software permite a los ordenadores coordinar sus actividades y compartir los recursos del sistema – hardware, software y datos. Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas estaciones de trabajo conectadas por una red de área local, hasta Internet, una colección de redes de área local y de área extensa interconectados, que en lazan millones de ordenadores. Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de cómputo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la información que el sistema mantiene. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de respuesta, proveer puntos de acceso al servicio que están distribuidos geográficamente, potencial para el crecimiento del sistema para acomodar la expansión del negocio y un marco para la integración de sistema usados por diferentes compañías y organizaciones de usuarios.
1.2
CARACTERÍSTICAS DE UN SISTEMA DISTRIBUIDO.
[Colouris 1994] establece que son seis las características principales responsables de la utilidad de los sistemas distribuidos. Se trata de comparación de recursos, apertura, concurrencia, escalabilidad, tolerancia a fallos y transparencia. 1.2.1 COMPARTICIÓN DE RECURSOS. El término ‘recurso’ es bastante abstracto, pero es el que mejor caracteriza el abanico de
entidades que pueden compartirse en un sistema distribuido. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros, ventanas, bases de datos y otros objetos de datos. La idea de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus usuarios. Sin embargo, los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o computadoras personales dentro de un sistema distribuido no obtienen automáticamente los beneficios de la compartición de recursos. Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente. Surge el término genérico de gestor de recursos. Un gestor de recursos es un módulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas políticas y métodos específicos junto con requisitos comunes para todos ellos. Éstos incluyen la provisión de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localización; la traslación de nombre de recurso a direcciones de comunicación y la coordinación de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia.
Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos. 1.2.2 APERTURA.
Un sistema informático es abierto si el sistema puede ser extendido de diversas maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos, memoria o interfaces de comunicación, etc …) o con respecto a las extensiones software (añadir características al sistema operativo, protocolos de comunicación y servicios de compartición de recursos, etc …). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el que nuevos servicios de compartición de recursos se pueden añadir sin perjudicar ni duplicar a los ya existentes. Básicamente los sistemas distribuidos cumplen una serie de características: 1. Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores. En una palabra, los interfaces se hacen públicos. 2. Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos. 3. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo, posiblemente proveniente de vendedores diferentes. Pero la conformidad de cada componente con el estándar publicado debe ser cuidadosamente comprobada y certificada si se quiere evitar tener problemas de integración. 1.2.3 CONCURRENCIA.
Cuando existen varios procesos en una única maquina decimos que se están ejecutando concurrentemente. Si el ordenador está equipado con un único procesador central, la concurrencia tiene lugar entrelazando la ejecución de los distintos procesos. Si la
computadora tiene N procesadores, entonces se pueden estar ejecutando estrictamente a la vez hasta N procesos. En los sistemas distribuidos hay muchas maquinas, cada una con uno o más procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutándose en paralelo. En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones: 1. Muchos usuarios interactúan simultáneamente con programas de aplicación. 2. Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a diferentes peticiones de los procesos clientes. El caso (1) es menos conflictivo, ya que normalmente las aplicaciones de interacción se ejecutan aisladamente en la estación de trabajo del usuario y no entran en conflicto con las aplicaciones ejecutadas en las estaciones de trabajo de otros usuarios. El caso (2) surge debido a la existencia de uno o más procesos servidores para cada tipo de recurso. Estos procesos se ejecutan en distintas maquinas, de manera que se están ejecutando en paralelo diversos servidores, junto con diversos programas de aplicación. Las peticiones para acceder a los recursos de un servidor dado pueden ser encoladas en el servidor y ser procesadas secuencialmente o bien pueden ser procesadas varias concurrentemente por múltiples instancias del proceso gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para asegurarse de que no existen conflictos. La sincronización debe ser cuidadosamente planeada para asegurar que no se pierden los beneficios de la concurrencia. 1.2.4 ESCALABILIDAD.
Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala más pequeña consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un sistema distribuido construido alrededor de una red de área local simple podría contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresión y otros servidores de propósito específico. A menudo
se conectan varias redes de área local para formar internetworks , y éstas podrían contener muchos miles de ordenadores que forman un único sistema distribuido, permitiendo que los recursos sean compartidos entre todos ellos. Tanto el software de sistema como el de aplicación no deberían cambiar cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware, sino que está íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos. El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario aparecerán serias limitaciones. La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debería ser posible extender el sistema para darla servicio. Por ejemplo, la frecuencia con la que se accede a los ficheros crece cuando se incrementa el número de usuarios y estaciones de trabajo en un sistema distribuido. Entonces, debe ser posible añadir ordenadores servidores para evitar el cuello de botella que se produciría si un solo servidor de ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. En este caso el sistema deberá estar diseñado de manera que permita trabajar con ficheros replicados en distintos servidores, con las consideraciones de consistencias que ello conlleva. Cuando el tamaño y complejidad de las redes de ordenadores crece, es un objetivo primordial diseñar software de sistema distribuido que seguirá siendo eficiente y útil con esas nuevas configuraciones de la red. Resumiendo, el trabajo necesario para procesar una petición simple para acceder a un recurso compartido debería ser prácticamente independiente del tamaño de la red. Las técnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la técnica asociada de caching, y el uso de múltiples servidores para manejar ciertas tareas, aprovechando la concurrencia para permitir una mayor productividad.
1.2.5 TOLERANCIA A FALLOS.
Los sistemas informáticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podrían producir resultados incorrectos o podrían pararse antes de terminar la computación que estaban realizando. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre sí: Redundancia hardware (uso de componentes redundantes) y recuperación del software (diseño de programas que sean capaces de recuperarse de los fallos). En los sistemas distribuidos la redundancia puede plantearse en un grano más fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas. La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo. Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podría desplazarse a otra estación de trabajo; un proceso servidor podría ejecutarse en otra máquina. 1.2.6 TRANSPARENCIA.
La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una colección de componentes independientes. La transparencia ejerce una gran influencia en el diseño del software de sistema. El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Las transparencias definidas son:
Transparencia de Acceso: Permite el acceso a los objetos de información remotos
de la misma forma que a los objetos de información locales. Transparencia de Localización: Permite el acceso a los objetos de información sin conocimiento de su localización Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de información compartidos y de forma que no exista interferencia entre ellos. Transparencia de Replicación : Permite utilizar múltiples instancias de los objetos de información para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicación tengan por que conoces la existencia de las réplicas. Transparencia de Fallos: Permite a los usuarios y programas de aplicación completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software. Transparencia de Migración: Permite el movimiento de objetos de información dentro de un sistema sin afectar a los usuarios o a los programas de aplicación. Transparencia de Prestaciones. Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia. Transparencia de Escalado: Permite la expansión del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicación.
Las dos más importantes son las transparencias de acceso y de localización; su presencia o ausencia afecta fuertemente a la utilización de los recursos distribuidos. A menudo se las denomina a ambas transparencias de red. La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en los sistemas centralizados. 1.3
MODELOS ARQUITECTÓNICOS.
Define: la forma en la que los componentes interactúan entre ellos: sus roles funcionales, el patrón de comunicación entre ellos. Cómo se asignan en los nodos de la red para distribuir los datos y para distribuir la carga. Elementos del modelo arquitectónico: 1. Paso de mensajes 2. Cliente-servidor
3. Peer-to-peer 4. MOM (Message-Oriented Middleware) Punto a punto Multicast (eventos con publish/subscribe) 5. RPC (Remote Procedure Call) 6. Objetos distribuidos RMI (Remote Method Invocation) Basado en ORB (Object Request Broker) 7. Agentes móviles
1.4
MODELOS FUNDAMENTALES.
CARACTERÍSTICAS GENERALES. El modelo funcional especifica lo que sucede, el modelo dinámico cuándo sucede, y el modelo de objetos sobre qué entidades sucede. Define el significado de: • •
Las operaciones y restricciones del Modelo de Objetos. Las acciones del Modelo Dinámico.
Sólo expresa qué valores de salida se derivan de qué valores de entrada. Consta de múltiples DFD´ s que muestran el flujo de valores desde las entradas externas, pasando por las operaciones y almacenes internos, hasta las salidas externas. DIAGRAMAS DE FLUJOS DE DATOS (DFD'S).
Notación clásica para definir el Modelo Funcional a través de múltiples DFDs. Un DFD muestra la relación funcional de los valores que calcula el sistema.
Sus elementos fundamentales son: • • • •
Procesos. Flujos de Datos (y en ocasiones, de control). Entidades Externas (Actores). Almacenes de Datos.
PROCESO
Un proceso es una transformación de datos. Los procesos de más bajo nivel son funciones puras sin efectos laterales. Pueden especificarse matemáticamente o en lenguaje natural. Un DFD entero puede verse como un proceso de más alto nivel. El Sistema puede verse como un proceso que se va descomponiendo por niveles.
Los procesos definen patrones de entradas y salidas. Se corresponden con operaciones de clases. El objeto destino suele ser uno de los objetos de entrada, sobre todo si esa misma clase es también un f lujo de salida. Se representan mediante elipses que contienen una descripción de la transformación, normalmente su nombre.
ACTORES.
Son objetos activos que conducen el DFD produciendo o consumiendo sus valores (terminadores). Definen los límites (el contexto) del sistema. Pueden ser usuarios del sistema o elementos hardware en Sistemas de TR. Representados por un cuadrado con el nombre del actor.
FLUJO DE DATOS.
Representan valores o conjuntos de valores que se transmiten de un cálculo a otro. Conectan la salida de un actor o proceso con la entrada de otro. Pueden descomponerse o duplicarse para ser entrada de diferentes procesos. Varios flujos de datos pueden unirse en uno para convertirse en un dato agregado.
ALMACENES DE DATOS.
Objetos pasivos que almacenan datos. Sólo responden a peticiones de obtener, eliminar o actualizar datos. Suelen ser conjuntos de datos heterogéneos a los que se puede acceder en orden diferente al de inserción. Se representan por un par de líneas paralelas que contienen el nombre del almacén.
FLUJOS DE CONTROL.
Un DFD no expresa relaciones temporales, de control, ni orden de ejecución. Sólo muestra los posibles caminos de cómputo. Existen funciones de decisión que no proporcionan datos pero sí son desencadenantes de otro proceso. Un flujo de control es un valor lógico que expresa un evento necesario para un cálculo. Sólo debemos usarlos cuando sean útiles, ya que duplican información del Modelo Dinámico. Existen Métodos basados en DFD’s con notaciones extendidas para denotar el control,
como CODARTS, para diseño de sistemas de TR distribuidos.
Niveles de descomposición de un DFD.
El proceso de definición del Modelo Funcional es usualmente descendente (topDown). Cualquier proceso puede descomponerse como un nuevo DFD que detalla su funcionamiento. Cada entrada o salida del proceso debe existir en el nuevo DFD. El nuevo DFD puede contener Almacenes que no se mostraban en el DFD de nivel superior. Podemos estudiar separadamente cada DFD en cualquier nivel del árbol.
Restricciones de un DFD.
Muestran relaciones en un instante de tiempo: Entre dos objetos (Ej.: frecuencia y longitud de onda). o Entre valores de un mismo objeto. o Estas relaciones pueden ser: Funciones totales: un valor se calcula a partir del otro. o o Funciones parciales: un valor impone restricciones al otro. Una restricción sobre los valores (estado) de un objeto a lo largo del tiempo es un invariante.
1.5
RECURSOS DE COMUNICACIÓN.
Las TIC (tecnologías de la información y comunicación) conforman el conjunto de recursos necesarios para manipular la información: los ordenadores, los programas informáticos y las redes necesarias para convertirla, almacenarla, administrarla, transmitirla y encontrarla. Se puede clasificar las TIC según:
Las redes. Los terminales. Los servicios.
Las redes Telefonía fija
El método más elemental para realizar una conexión a Internet es el uso de un módem en un acceso telefónico básico. A pesar que no tiene las ventajas de la banda ancha, este sistema ha sido el punto de inicio para muchos internautas y es una alternativa básica para zonas de menor poder adquisitivo. Banda ancha
La banda ancha originariamente hacía referencia a una capacidad de acceso a Internet superior al acceso analógico (56 kbps en un acceso telefónico básico o 128 kbps en un acceso básico RDSI). El concepto ha variado con el tiempo en paralelo a la evolución tecnológica. Según la Comisión federal de Comunicaciones de los EEUU (FCC) se considera banda ancha el acceso a una velocidad igual o superior a los 200 kbps, como mínimo en un sentido. Para la Unión Internacional de Telecomunicaciones el umbral se sitúa en los 2 Mbps.15 Internet está evolucionando muy rápidamente y está aumentando enormemente la cantidad de contenidos pesados (videos, música...). Por este motivo, los operadores se están encontrando en muchas ocasiones que las redes tradicionales no tienen suficiente capacidad para soportar con niveles de calidad adecuada el tránsito que se comienza a generar y prevén que el problema aumente con el tiempo, debido al ritmo actual de crecimiento.
Telefonía móvil
Mensaje MMS en un terminal móvil. A pesar de ser una modalidad más reciente, en todo el mundo se usa más la telefonía móvil que la fija. Se debe a que las redes de telefonía móvil son más fáciles y baratas de desplegar. El número de líneas móviles en el mundo continúa en crecimiento, a pesar que el grado de penetración en algunos países está cerca de la saturación. De hecho, en Europa la media de penetración es del 119%.17
Las redes actuales de telefonía móvil permiten velocidades medias competitivas en relación con las de banda ancha en redes fijas: 183 kbps en las redes GSM, 1064 kbps en las 3G y 2015 kbps en las WiFi.18 Esto permite a los usuario un acceso a Internet con alta movilidad, en vacaciones o posible para quienes no disponen de acceso fijo. Redes de televisión
Actualmente hay cuatro tecnologías para la distribución de contenidos de televisión, incluyendo las versiones analógicas y las digitales:
La televisión terrestre, que es el método tradicional de transmitir la señal de difusión de televisión, en forma de ondas de radio transmitida por el espacio abierto. Este apartado incluiría la TDT. La televisión por satélite, consistente en retransmitir desde un satélite de comunicaciones una señal de televisión emitida desde un punto de la Tierra, de forma que ésta pueda llegar a otras partes del planeta. La televisión por cable, en la que se transmiten señales de radiofrecuencia a través de fibras ópticas o cables coaxiales. La televisión por Internet traduce los contenidos en un formato que puede ser transportado por redes IP, por eso también es conocida como Televisión IP.
1.5.1 PROTOCOLOS TCP/IP.
TCP/IP es un conjunto de protocolos. La sigla TCP/IP significa "Protocolo de control de transmisión/Protocolo de Internet" y se pronuncia "T-C-P-I-P". Proviene de los nombres de dos protocolos importantes del conjunto de protocolos, es decir, del protocolo TCP y del protocolo IP. En algunos aspectos, TCP/IP representa todas las reglas de comunicación para Internet y se basa en la noción de dirección IP, es decir, en la idea de brindar una dirección IP a
cada equipo de la red para poder en rutar paquetes de datos. Debido a que el conjunto de protocolos TCP/IP originalmente se creó con fines militares, está diseñado para cumplir con una cierta cantidad de criterios, entre ellos:
Dividir mensajes en paquetes; Usar un sistema de direcciones; Enrutar datos por la red; Detectar errores en las transmisiones de datos.
El conocimiento del conjunto de protocolos TCP/IP no es esencial para un simple usuario, de la misma manera que un espectador no necesita saber cómo funciona su red audiovisual o de televisión. Sin embargo, para las personas que desean administrar o brindar soporte técnico a una red TCP/IP, su conocimiento es fundamental. La diferencia entre estándar e implementación
En general, TCP/IP relaciona dos nociones:
La noción de estándar: TCP/IP representa la manera en la que se realizan las comunicaciones en una red; La noción de implementación: la designación TCP/IP generalmente se extiende a software basado en el protocolo TCP/IP. En realidad, TCP/IP es un modelo cuya aplicación de red utilizan los desarrolladores. Las aplicaciones son, por lo tanto, implementaciones del protocolo TCP/IP.
TCP/IP es un modelo de capas
Para poder aplicar el modelo TCP/IP en cualquier equipo, es decir, independientemente del sistema operativo, el sistema de protocolos TCP/IP se ha dividido en diversos módulos. Cada uno de éstos realiza una tarea específica. Además, estos módulos realizan sus tareas uno después del otro en un orden específico, es decir que existe un sistema estratificado. Ésta es la razón por la cual se habla de modelo de capas. El término capa se utiliza para reflejar el hecho de que los datos que viajan por la red atraviesan distintos niveles de protocolos. Por lo tanto, cada capa procesa sucesivamente los datos (paquetes de información) que circulan por la red, les agrega un elemento de información (llamado encabezado) y los envía a la capa siguiente. El modelo TCP/IP es muy similar al modelo OSI (modelo de 7 capas) que fue desarrollado por la Organización Internacional para la Estandarización (ISO) para estandarizar las comunicaciones entre equipos.
1.5.2 SERVICIOS Y PUERTOS.
En un sistema distribuido, se usa algún nombre para hacer referencia a algún recurso como nodos de procesamiento (computadoras), puertos, servicios y usuarios. Los nombres son útiles al momento en que se desea establecer una comunicación o compartir recursos en un sistema distribuido. A continuación se listan algunos tipos de nombres:
Identificadores de puertos y procesos. Nombres textuales de servicios. Identificadores de recursos. Nombres de archivos. Direcciones físicas y lógicas de redes.
Muchos de los nombres usados en un sistema distribuido se refieren a un servicio en particular; por ejemplo, un cliente (usuario o proceso) usa tal nombre para solicitar un determinado servicio para ejecutar alguna operación sobre un objeto o recurso con un nombre propio. A la asociación entre un nombre y un objeto se llama liga o conexión. Cada objeto en un sistema tiene ciertos atributos. Por ejemplo, los servicios y las computadoras tienen direcciones físicas; los usuarios cuentan con direcciones de correo electrónico, números telefónicos y direcciones de sus computadoras personales, agregando llaves de acceso, directorios de trabajo, etc. En general, los valores de los atributos o son valores primitivos tales como enteros o son en sí nombres, o una dirección de Internet como 221.230.321.111. Servicios Servicio Descripción Windows Internet Naming Service. WINS
Es un servidor de nombres de Microsoft para NetBIOS. Mantiene una tabla con la correspondencia entre direcciones IP y nombres NetBIOS de PC. Esta lista permite localizar rápidamente a otro PC de la red. Dynamic Host Configuration Protocol. DHCP Protocolo Configuración Dinámica de Servidor Es de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después. TELNET TELecommunication NETwork Sirve para acceder mediante una red a otra máquina, para manejarla
FTP
POP
SMTP
SNMP
remotamente. Para que la conexión funcione, la máquina a la que se acceda debe tener un programa que reciba y gestione las conexiones. File Transfer Protocol Protocolo de Transferencia de Archivos Es un protocolo para la transferencia de archivos entre sistemas conectados a una red TCP, basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. Post Office Protocol. Protocolo de la oficina de correo. En clientes locales de correo para obtener los mensajes de correo electrónico almacenados en un servidor remoto. Simple Mail Transfer Protocol. Protocolo Simple de Transferencia de Correo. Protocolo basado en texto utilizado para el intercambio de mensajes de correo electrónico entre computadores u otros dispositivos (PDA's, teléfonos móviles, etc. Protocolo Simple de Administración de Red. Es un protocolo que facilita el intercambio de información de administración entre dispositivos de red. Permite a los administradores supervisar el funcionamiento de la red, buscar y resolver sus problemas, y planear su crecimiento.
El uso de puertos
Diversos programas TCP/IP pueden ejecutarse simultáneamente en Internet (por ejemplo, pueden abrirse diferentes navegadores de manera simultánea o navegar por páginas HTML mientras se descarga un archivo de un FTP). Cada uno de estos programas funciona con un protocolo. A veces el equipo debe poder distinguir las diferentes fuentes de datos. Por lo tanto, para facilitar este proceso, a cada una de estas aplicaciones puede serle asignada una dirección única en equipo, codificada en 16 bits: un puerto (por consiguiente, la combinación de dirección IP + puerto es una dirección única en el mundo denominada socket). De esta manera, la dirección IP sirve para identificar de manera única un equipo en la red mientras que el número de puerto especifica la aplicación a la que se dirigen los datos. Así, cuando el equipo recibe información que va dirigida a un puerto, los datos se envían a la aplicación relacionada. Si se trata de una solicitud enviada a la aplicación, la aplicación se denomina aplicación servidor. Si se trata de una respuesta, entonces hablamos de una aplicación cliente.
La función de multiplexación
El proceso que consiste en poder enviar información desde varias aplicaciones a través de una conexión se denomina multiplexación. De la misma manera, la tarea de administrar poniendo en paralelo (por lo tanto compartiendo entre varias aplicaciones) el flujo de datos se denomina demultiplexación. Estas operaciones se pueden realizar gracias a un puerto, es decir, un número relacionado con un tipo de aplicación que, combinado con una dirección IP, permite determinar de manera única una aplicación que se está ejecutando en un determinado equipo. Asignaciones predeterminadas
Existen miles de puertos (codificados en 16 bits, es decir que se cuenta con 65536 posibilidades). Es por ello que la IANA (Internet Assigned Numbers Authority [Agencia de Asignación de Números de Internet]) desarrolló una aplicación estándar para ayudar con las configuraciones de red. Los puertos del 0 al 1023 son los "puertos conocidos" o reservados. En términos generales, están reservados para procesos del sistema (daemons) o programas ejecutados por usuarios privilegiados. Sin embargo, un administrador de red puede conectar servicios con puertos de su elección. Los puertos del 1024 al 49151 son los "puertos registrados". Los puertos del 49152 al 65535 son los "puertos dinámicos y/o privados".
A continuación se indican algunos de los puertos conocidos más utilizados: Puerto
Servicio o aplicación
21
FTP
23
Telnet
25
SMTP
53
Sistema de nombre de dominio
63
Whois
70
Gopher
79
Finger
80
HTTP
110
POP3
119
NNTP
Por lo tanto, un servidor (un equipo conectado que ofrece servicios como FTP, Telnet, etc.) cuenta con números de puerto fijos a los cuales el administrador de red conecta los servicios. Entonces, los puertos del servidor generalmente se encuentran entre 0 y 1023 (rango de valores relacionado con servicios conocidos). Del lado del cliente, el sistema operativo elige el puerto entre aquéllos que están disponibles de forma aleatoria. Por lo tanto, los puertos del cliente nunca incluirán los puertos que se encuentran entre 0 y 1023, ya que este rango de valores representa a los puertos conocidos. 1.5.3 PROCESOS Y DEMONIOS. Demonios
Los demonios (daemons) son aplicaciones especiales del sistema que normalmente se ejecutan continuamente en segundo plano esperando peticiones provenientes de otras aplicaciones que deseen usar las funciones que proporcionan. Muchos demonios están centrados en la red; es decir, muchos de los demonios que se ejecutan en segundo plano en un sistema Ubuntu pueden proporcionar funcionalidades relacionadas con la red. Algunos ejemplos de tales demonios de red incluyen el demonio de protocolo de transporte de hipertexto (httpd), que proporciona funcionalidades de servidor web; el demonio de intérprete seguro (sshd), que proporciona capacidades seguras de sesiones interactivas remotas y transferencia de archivos; y el demonio de protocolo de acceso a mensajes de Internet (imapd), que proporciona servicios de correo electrónico.
UNIDAD II
2
PROCEDIMIENTO DISTRIBUIDO
2.1
INTRODUCCIÓN A LOS SISTEMAS DE MULTIPROCESAMIENTO.
Pueden clasificarse en esta categoría muchos sistemas multiprocesadores y sistemas multicomputadores. Un multiprocesador se define como una computadora que contiene dos o más unidades de procesamiento que trabajan sobre una memoria común bajo un control integrado. Si el sistema de multiprocesamiento posee procesadores de aproximadamente igual capacidad, estamos en presencia de multiprocesamiento simétrico; en el otro caso hablamos de multiprocesamiento asimétrico. Todos los procesadores deben poder acceder y usar la memoria principal. De acuerdo a esta definición se requiere que la memoria principal sea común y solamente existen pequeñas memorias locales en cada procesa- dor. Si cada procesador posee una gran memoria local se lo puede considerar un sistema de multicomputadoras, el cual puede ser centralizado o distribuido. Todos los procesadores comparten el acceso a canales de E/S, unidades de control y dispositivos. Para el sistema de multiprocesamiento debe existir un sistema operativo integrado, el cual controla el hardware y el software y debe asegurar la interacción entre los procesadores y sus programas al nivel elemental de dato, conjunto de datos y trabajos. Una computadora MIMD intrínseca implica interacciones entre n procesadores debido a que todos los flujos de memoria se derivan del mismo espacio de datos compartido por todos los procesadores. Si los n flujos de datos provienen de subespacios disjuntos de memorias compartidas, entonces estamos en presencia del denominado operación SISD múltiple, que no es otra cosa que un conjunto de n monoprocesadores SISD. Una MIMD intrínseca está fuertemente acoplada si el grado de interacción entre los procesadores es alto. De otra manera consideramos el sistema como débilmente acoplado. Muchos sistemas comerciales son débil- mente acoplados, a saber, la IBM 370/168, Univac 1100/80, IBM 3081/3084, etc. Existen similitudes entre los sistemas multiprocesadores y multicomputadores debido a que ambos fueron pensados con un mismo objetivo: dar soporte a operaciones concurrentes en el sistema. Sin embargo, existen diferencias importantes basadas en el alcance de los recursos compartidos y la cooperación en la solución de un problema.
Un sistema multicomputador consiste de diversas computadoras autónomas que pueden o no comunicar- se entre sí. Un sistema multiprocesador está controlado por un sistema operativo que provee la interacción entre los procesadores y sus programas a nivel de dato, proceso y archivo. 2.2
CLASIFICACIÓN DE LOS SISTEMAS DE MULTIPROCESAMIENTO.
Los sistemas multiprocesador pueden clasificarse en:
Multiprocesador débilmente acoplado Procesadores especializados Multiprocesador fuertemente acoplado
2.2.1 FUERTEMENTE ACOPLADOS.
Consta de un conjunto de procesadores que comparten una memoria principal común y se encuentran bajo el control integrado de un S.O. 2.2.2 DÉBILMENTE ACOPLADOS.
Consta de un conjunto de sistemas relativamente autónomos, donde cada procesador tiene su propia memoria principal y sus propios canales de E/S. 2.2.3 ESPECIALIZADOS. Similares a los procesadores de E/S. Hay un procesador principal de propósito general
que controla y ofrece servicios a los procesadores especializados. 2.3
SISTEMAS DE CLUSTERS.
Qué es exactamente un sistema Cluster?
Este tipo de sistemas se basa en la unión de varios servidores que trabajan como si de uno sólo se tratase. Los sistemas cluster han evolucionado mucho desde su primera aparición, ahora se pueden crear distintos tipos de clusters, en función de lo que se necesite:
Unión de Hardware Clusters de Software Alto rendimiento de bases de datos
Estas son solo algunas de las opciones que tenemos disponibles. En resumen, cluster es un grupo de múltiples ordenadores unidos mediante una red de alta velocidad, de tal forma que el conjunto es visto como un único ordenador, más potente que los comunes
de escritorio. De un sistema de este tipo se espera que presente combinaciones de los siguientes servicios:
Alto rendimiento Alta disponibilidad Equilibrio de carga Escalabilidad
Para que un sistema cluster funcione no es necesario que todas las máquinas dispongan del mismo Hardware y sistema operativo (cluster heterogéneo). Este tipo de sistemas debe de disponer de un interfaz de manejo de clusters, la cual se encargue de interactuar con el usuario y los procesos, repartiendo la carga entre las diferentes máquinas del grupo. ¿Qué componentes necesita un cluster para funcionar? Por norma general un cluster hace uso de diferentes componentes para funcionar, entre estos están:
Nodos (Ordenadores o servidores) Sistema operativo Conexión de Red (ampliado más abajo) Middleware (capa entre el usuario y el sistema operativo) Protocolos de comunicación y servicio Aplicaciones
Nodos:
Los nodos pueden ser ordenadores de escritorio o servidores, de hecho se puede establecer un cluster con cualquier tipo de máquina. Sistema operativo:
Este debe de tener un entorno multiusuario, cuanto más fácil sea el manejo del sistema menores problemas tendremos. Comúnmente Solingest instala sus cluster con sistemas Microsoft Cluster Services (MSCS), pero es totalmente factible la instalación de un Cluster con un sistema Linux o Unix como podrían ser Rocks (Linux) o Solaris (Unix). Han surgido ocasiones en las que se ha requerido el montaje de un sistema cluster en Mac OS X, sobretodo en Granjas de render (para procesado 3D). Conexiones de Red:
Las conexiones utilizadas en este tipo de sistema pueden ser muy variadas, se pueden utilizar desde simples conexiones Ethernet con placas de red comunes o sistemas de alta velocidad como Fast Ethernet, Gigabit Ethernet, Myrinet, Infiniband, SCI, etc. Middleware:
El middleware es el software que actúa entre el sistema operativo y las aplicaciones y que brinda al usuario la experiencia de estar utilizando una única super máquina. Este software provee una única interfaz de acceso al sistema, denominada SSI (Single System Image). Optimiza el sistema y provee herramientas de mantenimiento para procesos pesados como podrían ser migraciones, balanceo de carga, tolerancia de fallos, etc. Este sistema también se encarga de la escalabilidad del cluster, detectando nuevas máquinas y añadiéndolas al grupo. Por lo tanto, si un cliente quisiera disponer de un cluster para su servidor Web, este podría optar entre diferentes opciones. No habría ningún problema en instalar un cluster que tuviese un sistema MySQL y PHP repartido entre diferentes máquinas. ¿Tiene alguna desventaja? Ninguna, este tipo de sistemas son los más fiables, ya que para la parada total del proceso deben de pararse todas las máquinas que componen el grupo. Es la mejor solución para crecer según las necesidades reales, ya que puede añadir tantas máquinas necesite. Empresas muy importantes como Google y Microsoft utilizan este tipo de sistemas para poner en marcha sus portales. Realmente con este tipo de soluciones las posibilidades son inmensas. 2.3.1 MULTIPROCESAMIENTO DEDICAD Y COPARTIDO.
El cluster puede estar conformado por nodos dedicados o por nodos no dedicados. En un cluster con nodos dedicados, los nodos no disponen de teclado, mouse ni monitor y su uso está exclusivamente dedicado a realizar tareas relacionadas con el cluster. Mientras que, en un cluster con nodos no dedicados, los nodos disponen de teclado, mouse y monitor y su uso no está exclusivamente dedicado a realizar tareas relacionadas con el cluster, el cluster hace uso de los ciclos de reloj que el usuario del computador no está utilizando para realizar sus tareas. Cabe aclarar que a la hora de diseñar un Cluster, los nodos deben tener características similares, es decir, deben guardar cierta similaridad de arquitectura y sistemas operativos, ya que si se conforma un Cluster con Nodos totalmente heterogéneos (existe una diferencia grande entre capacidad de procesadores, memoria, HD) sera ineficiente
debido a que el middleware delegara o asignara todos los procesos al Nodo de mayor capacidad de Cómputo y solo distribuirá cuando este se encuentre saturado de procesos; por eso es recomendable construir un grupo de ordenadores los más similares posible. El almacenamiento puede consistir en una NAS, una SAN, o almacenamiento interno en el servidor. El protocolo más comúnmente utilizado es NFS (Network File System), sistema de ficheros compartido entre servidor y los nodos. Sin embargo existen sistemas de ficheros específicos para clusters como Lustre (CFS) y PVFS2. Mientras NAS permite compartir el almacenamiento, utilizar la red, y tiene una gestión más sencilla, DAS proporciona mayor rendimiento y mayor fiabilidad al no compartir el recurso. 2.4
PROTOCOLOS DE COMUNICACIÓN.
Un protocolo es un conjunto bien conocido de reglas y formatos que se utilizan para la comunicación entre procesos que realizan una determinada tarea. Se requieren dos partes: Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. Un protocolo permite que componentes heterogéneos de sistemas distribuidos puedan desarrollarse independientemente, y por medio de módulos de software que componen el protocolo, haya una comunicación transparente entre ambos componentes. Es conveniente mencionar que estos componentes del protocolo deben estar tanto en el receptor como en el emisor. Ejemplos de protocolos usados en los sistemas distribuidos: IP: Protocolo de Internet.- Protocolo de la capa de Red, que permite definir la
unidad básica de transferencia de datos y se encarga del direccionamiento de la información, para que llegue a su destino en la red. TCP: Protocolo de Control de Transmisión.- Protocolo de la capa de Transporte,
que permite dividir y ordenar la información a transportar en paquetes de menor tamaño para su transporte y recepción. HTTP: Protocolo de Transferencia de Hipertexto.- Protocolo de la capa de
aplicación, que permite el servicio de transferencia de páginas de hipertexto entre el cliente WEB y los servidores. SMTP: Protocolo de Transferencia de Correo Simple.- Protocolo de la capa de
aplicación, que permite el envío de correo electrónico por la red.
POP3: Protocolo de Oficina de Correo Protocolo de la capa de aplicación, que .-
permite la gestión de correos en Internet, es decir, le permite a una estación de trabajo recuperar los correos que están almacenados en el servidor. 2.5
PASO DE MENSAJES.
Un proceso manda un mensaje que es recibido por otro proceso que suele esperar dicho mensaje. El paso de mensajes es imprescindible en sistemas distribuidos dado que en este caso no existen recursos directamente compartidos para intercambiar información entre los procesos. Sin embargo, también si se trabaja con un solo procesador pasar mensajes entre procesos es un buen método de sincronizar procesos o trabajos, respectivamente. Existen muchas variantes de implementaciones de paso de mensajes. Destacamos unas características. 2.6
OBJETOS REMOTOS
En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un "método de invocación remota". El cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje. Las tres tecnologías importantes y más usadas en este ámbito son: RMI.- Remote Invocation Method.- Fue el primer fremework para crear sistemas
distribuidos de Java. El sistema de Invocación Remota de Métodos (RMI) de Java permite, a un objeto que se está ejecutando en una Máquina Virtual Java (VM), llamar a métodos de otro objeto que está en otra VM diferente. Esta tecnología está asociada al lenguaje de programación Java, es decir, que permite la comunicación entre objetos creados en este lenguaje. DCOM.- Distributed Component Object Model.- El Modelo de Objeto Componente
Distribuido, esta incluido en los sistemas operativos de Microsoft. Es un juego de conceptos e interfaces de programa, en el cual los objetos de programa del cliente, pueden solicitar servicios de objetos de programa servidores en otros ordenadores dentro de una red. Esta tecnología está asociada a la plataforma de productos Microsoft. CORBA.- Common Object Request Broker Architecture.- Tecnología introducida por el
Grupo de Administración de Objetos OMG, creada para establecer una plataforma para la gestión de objetos remotos independiente del lenguaje de programación.
2.7
PROCEDIMIENTOS REMOTOS.
El RPC (del inglés Remote Procedure Call , Llamada a Procedimiento Remoto ) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC. Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente. Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor. Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden ser SOAP o XML-RPC.
UNIDAD III
3
ALMACENAMIENDO DE DATOS DISTRIBUIDOS
3.1
ALMACENAMIENTO DE ALTA DISPONIBILIDAD.
Alta disponibilidad (High availability) es un protocolo de diseño del sistema y su implementación asociada que asegura un cierto grado absoluto de continuidad operacional durante un período de medición dado. Disponibilidad se refiere a la habilidad de la comunidad de usuarios para acceder al sistema, someter nuevos trabajos, actualizar o alterar trabajos existentes o recoger los resultados de trabajos previos. Si un usuario no puede acceder al sistema se dice que está no disponible. El término tiempo de inactividad (downtime) es usado para definir cuándo el sistema no está disponible. Tiempo de inactividad
Típicamente tiempo de inactividad planificado es un resultado del mantenimiento que es perjudicial para la operación del sistema y usualmente no puede ser evitado con la configuración del sistema actualmente instalada. Eventos que generan tiempos de inactividad planificados quizás incluyen parches al software del sistema que requieran un rearranque o cambios en la configuración del sistema que toman efecto después de un rearranque. En general el tiempo de inactividad planificado es usualmente el resultado de un evento lógico o de gestión iniciado. Tiempos de inactividad no planificado surgen de algún evento físico tales como fallos en el hardware o anomalías ambientales. Ejemplos de eventos con tiempos de inactividad no planificados incluyen fallos de potencia, fallos en los componentes de CPU o RAM, una caída por recalentamiento, una ruptura lógica o física en las conexiones de red, rupturas de seguridad catastróficas o fallos en el sistema operativo, aplicaciones y middleware. Muchos puestos computacionales excluyen tiempo de inactividad planificado de los cálculos de disponibilidad, asumiendo, correcta o incorrectamente, que el tiempo de actividad no planificado tiene poco o ningún impacto sobre la comunidad de usuarios computacionales. Excluyendo tiempo de inactividad planificado, muchos sistemas pueden reclamar tener alta disponibilidad fenomenal, la cual da la ilusión de disponibilidad continua. Sistemas que exhiben verdadera disponibilidad continua son comparativamente raros y caros, y ellos tienen diseños cuidadosamente implementados que eliminan cualquier punto de fallo y permiten que el hardware, la red, el sistema operativo, middleware y actualización de aplicaciones, parches y reemplazos se hagan en línea.
Cálculos porcentuales
Disponibilidad es usualmente expresada como un porcentaje del tiempo de funcionamiento en un año dado. En un año dado, el número de minutos de tiempo de inactividad no planeado es registrado para un sistema, el tiempo de inactividad no planificado agregado es dividido por el número total de minutos en un año (aproximadamente 525.600) produciendo un porcentaje de tiempo de inactividad; el complemento es el porcentaje de tiempo de funcionamiento el cual es lo que denominamos como disponibilidad del sistema. Valores comunes de disponibilidad, típicamente enunciado como número de "nueves" para sistemas altamente disponibles son: 99,9% = 43.8 minutos/mes u 8,76 horas/año ("tres nueves") 99,99% = 4.38 minutos/mes o 52.6 minutos/año ("cuatro nueves") 99,999% = 0.44 minutos/mes o 5.26 minutos/año ("cinco nueves") Es de hacer notar que tiempo de funcionamiento y disponibilidad no son sinónimos. Un sistema puede estar en funcionamiento y no disponible como en el caso de un fallo de red. Se puede apreciar que estos valores de disponibilidad son visibles mayormente en documentos de ventas o marketing, en lugar de ser una especificación técnica completamente medible y cuantificable. Medida e interpretación
Claramente como la disponibilidad medida está sujeta a algún grado de interpretación. Un sistema que ha estado en funcionamiento por 365 días en un año no bisiesto quizá ha sido eclipsado por un fallo de red que duro 9 horas durante un periodo de uso pico; la comunidad de usuarios verá el sistema como no disponible, mientras el administrador del sistema reclamara el 100% de “tiempo de funcionamiento”. Sin embargo siguiendo
la verdadera definición de disponibilidad, el sistema estará aproximadamente 99.897% disponible (8751 horas de time out de las 8760 horas por año no bisiesto). También sistemas experimentando problemas de rendimiento son frecuentemente estimados como entera o parcialmente no disponibles por los usuarios mientras administradores quizás tengan una diferente (y probablemente incorrecta, ciertamente en el sentido del negocio) percepción. Similarmente no disponibilidad de funciones de aplicación no seleccionadas quizás pasen inadvertidas para administradores sin embargo podrían ser devastadoras para usuarios una verdadera medida de disponibilidad es integral. Disponibilidad debe ser medida para ser determinada, idealmente con herramientas de monitorización comprensivas ("instrumentación") que son ellas mismas altamente
disponibles. Si hay una falta de instrumentación, sistemas soportando un alto volumen de procesamiento de transacciones a través del día y la noche tales como procesamiento de tarjetas de crédito o conmutadores telefónicos, son frecuentemente e inherentemente mejor monitorizados, al menos por los mismos usuarios, que sistemas que experimentan pausas periódicas en la demanda. Diseño de un sistema de alta disponibilidad
Paradójicamente, añadiendo más componentes al sistema total puede socavar esfuerzos para lograr alta disponibilidad. Esto es debido a que sistemas complejos tienen inherentemente más puntos de fallos potenciales y son más difíciles de implementar correctamente. La mayoría de los sistemas altamente disponibles extraen a un patrón de diseño simple: un sistema físico multipropósito simple de alta calidad con redundancia interna comprensible ejecutando todas las funciones intedependientes emparejadas con un segundo sistema en una localización física separada. Este clásico patrón de diseño es común entre instituciones financieras por ejemplo. La industria de la informática y las comunicaciones ha establecido el Servicio Forum de la Disponibilidad acogerá la creación de productos de infraestructura de red, servicios y sistemas de alta disponibilidad. El mismo principio de diseño básico se aplica más allá de la informática en diversos campos como potencia nuclear, aeronáutica y cuidados médicos. 3.2
SERVICIOS LOCALES DE ALTA DISPONIBILIDAD.
La Alta Disponibilidad consiste en una serie de medidas tendientes a garantizar sus operaciones tecnológicas. NeverOff Technology se ha esforzado en agrupar una serie de componentes que le permitirá a su empresa tener disponibilidad de sus Servidores y Aplicativos 24x7x365 días del año. Teniendo en cuenta todos los posibles accidentes y desastres que pueden sufrir sus servidores o sistemas de información, la planificación de contingencias debería ser una tarea de máxima prioridad para todas las empresas. Al implementar esta solución o servicio de alta disponibilidad por NeverOff Technology, las empresas pueden contar con que no perderán negocios, información ni tiempo debido a fallas en sus sistemas. Cuente con un servidor remoto que hará de servidor secundario espejo o “mirror” en un Data Center de clase mundial en el cual se lleva a
cabo sincronizaciones de la data de forma segura y simultánea con los sistemas locales. Llámenos o contáctenos y compruebe como nuestro Servicio de Alta Disponibilidad le permitirá ser más productivo, tener continuidad operativa de su negocio y ahorrar costos operacionales.
3.2.1 ARREGLOS DE DISCO.
Los arreglos redundantes de discos económicos originales son 5, desde el RAID 1 hasta el RAID 5, y de manera similar comúnmente se hace referencia a un arreglo de discos sin redundancia como RAID 0, aunque dado que no tiene redundancia quizá el nombre más apropiado sería AID. Con el tiempo y la creación de circuitos más veloces nacieron nuevos esquemas y arquitecturas que superan a los niveles originales en diversas características. RAID nivel 0 requiere al menos dos platinas de disco para poder ser implementado. Funcionamiento RAID 0 implementa un arreglo de discos en franjas en donde los datos son divididos en bloques y cada bloque es almacenado en un disco distinto. Ventajas En esta configuración un arreglo de discos mejora el desempeño de entrada/salida al distribuir la carga de escritura y lectura a través de varios canales y platinas de disco. El mejor desempeño es alcanzado cuando los datos son distribuidos en varios controladores con sólo un disco por controlador.
No hay sobrecarga por el cálculo de paridad Diseño simple Sencillez de implementación.
Desventajas
No es un RAID debido a que no es redundante ni tolerante a fallas La falla de una platina resulta en la pérdida de los datos de todo el arreglo.
Recomendaciones
Nunca se debe de utilizar en ambientes de misión crítica. Es muy útil en producción y edición de vídeo e imágenes, así como aplicaciones de pre impresión. En general para aplicaciones que requieran de un alto ancho de banda.
RAID nivel 1 requiere al menos dos platinas de disco para poder ser implementado. Para mejor desempeño, el controlador debe de ser capaz de realizar dos lecturas concurrentes independientes por par espejo o dos escrituras duplicadas por par de discos en espejo. Funcionamiento
RAID 1 implementa un arreglo de discos en espejo en donde los datos son leídos y escritos de manera simultánea en dos discos distintos. Ventajas En esta configuración un arreglo de discos puede realizar una escritura o dos lecturas por par en espejo, duplicando la tasa de transaccional de lectura de discos simples con la misma tasa transaccional de escritura que los discos tradicionales. Una redundancia total de datos significa que no es necesaria la reconstrucción en caso de falla de algún disco, sino sólo una copia.
La tasa de transferencia por bloques es la misma que en los discos tradicionales. Bajo ciertas circunstancias RAID 1 puede soportar fallas simultáneas múltiples de discos. Es el diseño RAID más simple. Sencillez de implementación.
Desventajas
Es el que tiene mayor derroche de disco de todos los tipos de RAID, con el 100% de derroche. Típicamente la función RAID es llevada a cabo por el software del sistema cargando a la UCP ó al servidor, degradando el desempeño del mismo. Probablemente no soporte cambio en caliente de un disco dañado cuando se implementa por software.
Recomendaciones
Buscar una implementación por hardware. Funciones administrativas y financieras. En general para aplicaciones que requieran de una alta disponibilidad.
3.2.2 MANEJO DE TRANSACCIONES.
Los sistemas distribuidos son muy confiables debido a la posibilidad de brindar redundancia y autonomía de recursos en diferentes nodos, esto posibilita detectar y localizar fallas, sin embargo tenemos varios aspectos que representan problemas para la integridad de los recursos y que a su vez motivan el uso de transacciones
Dificultad para mantener consistencia en los datos Una misma vía de comunicación no siempre puede ser utilizada para suministrar interacción entre dos procesos Requerimientos de procesamientos en paralelo Manejo interactivo de uno o más usuarios
Integridad de transacciones
Una transacción es una serie de operaciones sobre la base de datos consideradas como una única operación, de manera que cuando se cierra la transacción la base de datos queda en un estado consistente. Las restricciones de integridad de transacciones gobiernan las formas en que se puede manipular la base de datos. A diferencia de otras restricciones, las restricciones de transacción versan sobre el procesamiento y, por tanto, por sí mismas no son parte del modelo de datos. La base de datos debe respetar todas las restricciones de integridad definidas antes de que comience la transacción y una vez finalizada ésta, aunque se pueden violar temporalmente algunas de las restricciones durante la tr ansacción. Las transacciones pueden involucrar a múltiples registros, múltiples relaciones e incluso múltiples bases de datos. Siendo precisos, todas las operaciones sobre una base de datos son transacciones. Incluso la actualización de un único registro existente es una transacción. Estas transacciones de bajo nivel las realiza el motor de base de datos de forma transparente y, normalmente se puede ignorar este nivel de detalle. Aplicaciones de transacciones
Base de datos Base de datos distribuidas Sistema de archivos distribuidos Desarrollo de aplicaciones tolerantes a fallos
Definición de transacciones
Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento de los datos de las aplicaciones y que dependían de la consistencia de la información almacenada. Las transacciones son mecanismos que ayudan a simplificar la construcción de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y sincronizar operaciones como:
Operaciones de comparación de datos Aseguramiento de la seriabilidad de las transacciones con otras Atomicidad en su comportamiento Recuperación de fallas
La palabra transacción describe una secuencia de operaciones con uno o más recursos que transforman su estado actual en un nuevo estado de consistencia. Es un conjunto de
operaciones sobre datos que son tratadas como una unidad. Una transacción puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente. 3.3
SERVICIOS DISTRIBUIDOS DE ALTA DISPONIBILIDAD.
En este tipo de sistemas se busca un nivel de servicio aceptable utilizando un conjunto mínimo de gestores de réplicas conectados al cliente. Y debería minimizar el tiempo que el cliente espera hasta que los gestores de réplicas procesen una respuesta. A continuación se detallan tres sistemas (Cotilleo, Bayou y Coda) que proporcionan servicios con alta disponibilidad. 3.3.1 SERVICIOS DE ALMACÉN DE ARCHIVOS.
Se estructura en tres componentes: un servicio de archivos plano, un servicio de directorio y un módulo cliente. • Servicio de archivos plano: Se relaciona con la implementación de operaciones en
el contenido de los archivos. Se usan UFID (identificadores únicos de archivos) para referirse a ellos en las solicitudes de operaciones. Si recibe una solicitud para crear un archivo nuevo, genera un nuevo UFID y lo devuelve al solicitante. • Servicio de directorio: Permite transformar entre nombres de texto de los archivos
y sus UFID correspondientes. Mediante el nombre se puede obtener el UFID. Tiene operaciones para generar directorios, para añadir nuevos nombres de archivo a los directorios y para obtener UFID desde los directorios. Hace las veces de cliente del servicio de archivos plano. • Módulo cliente: Integra y extiende las operaciones del servicio de archivos plano y el
servicio de directorio bajo una interfaz de programación de aplicaciones sencilla. Puede implementar una caché de los bloques de archivos que ha usado recientemente. • Interfaz del servicio de archivos plano : En la figura 8.6 (página 301) se puede
observar una definición de la interfaz para un servicio de archivos planos (la interfaz RPC). Si IdArchivo contiene un UFID inválido o el usuario no tiene permisos suficientes, se lanzan excepciones (un caso aparte es la operación Crea, evidentemente). Las operaciones más importantes son las de lectura y escritura. Tenemos otras, como DameAtributos y PonAtributos, con las que se puede acceder al registro de los atributos (PonAtributos suele estar restringida al servicio de directorio que accede al archivo). Es sencillo construir un módulo cliente que emule las llamadas al sistema UNIX en términos de las operaciones de nuestro servicio de archivos planos y el servicio de directorio. El servicio de archivos planos no tiene (al contrario que UNIX) operaciones
open y close, sino que se accede a los archivos directamente. Podemos encontrar dos diferencias importantes entre ambas interfaces: Operaciones repetibles: En la interfaz del servicio de archivos planos, las operaciones son idempotentes (si se ejecutan repetidas veces, el resultado es el mismo), excepto Crear, que cada vez creará un fichero nuevo. En UNIX, las operaciones de lectura y escritura mueven un puntero, por lo que cada operación no generará el mismo resultado que la anterior. Servidores sin estado: Pueden ser rearrancados tras un fallo y reanudar la operación sin que cliente y servidor tengan que restablecer su estado. Control de acceso: En UNIX, los permisos se comprueban al solicitar la apertura de
un archivo en cierto modo. El UID del usuario utilizado en la comprobación de derechos es el resultado del login autenticado anterior del usuario y no puede ser alterado en las implementaciones no distribuidas. Los derechos se mantienen hasta que se cierra el archivo. En las implementaciones distribuidas, la comprobación se realiza en el servidor y la identidad se pasa con cada solicitud. No se mantienen los derechos, porque entonces el servidor no sería sin estado. Puede realizarse entonces de dos formas: se puede realizar una comprobación de acceso cuando se convierte u nombre de archivo en un UFID, codificando los resultados en forma de habilitación, que se devuelve al cliente (se reenvía en futuras solicitudes). También se puede enviar la identidad del usuario con cada solicitud del cliente y comprobar cada vez (este es más común). Interfaz del servicio de directorio: Puede verse una definición de interfaz RPC
para un servicio de directorio en la Figura 8.7 (página 303). Este servicio permite trasladar nombres a UFID, manteniendo las equivalencias para tal fin. Cada operación necesita el UFID del archivo objetivo, el cual se busca en este servicio. Tenemos dos operaciones posibles para modificar: AñadeNombre (añade una entrada al directorio e incrementa el contador de referencias en el registro de atributos de archivo) y DesNombra (elimina una entrada de un directorio y decrementa el contador. Si éste llega a 0, se elimina el archivo). Además, DameNombres permite a los clientes examinar el contenido de los directorios, seleccionando nombres mediante comparación de patrones frente a una expresión regular proporcionada por el cliente. •Sistema de archivos jerárquico : UNIX es un ejemplo que proporciona este
sistema. Los archivos forman un árbol de jerarquías. Cada archivo puede ser referenciado mediante un path. En UNIX no es un sistema estricto, ya que un archivo puede tener varios nombres o estar en varios directorios (mediante link).
Este tipo de sistema se puede implementar desde el módulo cliente usando los servicios de directorio y de archivos planos. Se construye un árbol de directorios con los archivos en las hojas. Su raíz es un directorio con una UFID bien conocida. Los atributos asociados con los archivos han de incluir un tipo que distingue a los archivos de los directorios. • Agrupación de archivos: Se conoce como grupo de archivos a una colección de
archivos ubicados en un servidor dado. Los grupos pueden reubicarse, pero un archivo no puede cambiar de grupo. Permiten la asignación de archivos a servidores de archivos almacenados en varios servidores. La representación de UFID de los sistemas que permiten esto tienen otro identificador para el grupo (debe ser único (se generan con un algoritmo que asegure la unicidad global)). 3.4
SERVICIOS DE DIRECTORIOS Y BÚSQUEDA.
Un directorio es una base de datos optimizada para lectura, navegación y búsqueda. Los directorios tienden a contener información descriptiva basada en atributos y tienen capacidades de filtrado muy sofisticada. Los directorios generalmente no soportan transacciones complicadas ni esquemas de vuelta atrás como los que se encuentran en los sistemas de bases de datos diseñados para manejar grandes y complejos volúmenes de actualizaciones. Las actualizaciones de los directorios son normalmente cambios simples, o todo o nada, siempre y cuando estén permitidos. Los directorios están afinados para dar una rápida respuesta a grandes volúmenes de búsquedas. Estos tienen la capacidad de replicar la información para incrementar la disponibilidad y la fiabilidad, al tiempo que reducen los tiempos de respuesta. Cuando la información de un directorio se replica, se pueden producir inconsistencias temporales entre las réplicas mientras esta se está sincronizando. Hay muchas formas diferentes de proveer un servicio de directorio. Diferentes métodos permiten almacenar distintos tipos de información en el directorio, tener distintos requisitos sobre como la información ha de ser referenciada, consultada y actualizada, como es protegida de los accesos no autorizados, etc. Algunos servicios de directorio son locales, es decir, proveen el servicio a un contexto restringido (como por ejemplo, el servicio finger en una única máquina). Otros servicios son globales y proveen servicio a un contexto mucho más amplio (como por ejemplo, Internet). Los servicios globales normalmente son distribuidos, esto significa que los datos están repartidos a lo largo de distintos equipos, los cuales cooperan para dar el servicio de directorio. Típicamente, un servicio global define un espacio de nombres uniforme que da la misma visión de los datos, independientemente de donde se esté, en relación a los propios datos. El servicio DNS (Domain Name System) es un ejemplo de un sistema de directorio globalmente distribuido.
Un servicio de búsqueda URN relaciona los URN con su URL correspondiente, la cual puede variar en el tiempo (sin que varíe el URN). Si un administrador cambia la URL, debe registrar la nueva en el servicio de búsqueda. La forma de un URN es la siguiente: urn:espacioNombres:nombreEspecíficoespacioNombres. Existe otro subconjunto de los URN llamado Características de Recurso Uniformes (URC) (o Citas de Recursos Uniformes). Se trata de descripciones de un recurso web, escrito en forma de pares nombre-valor. Permite realizar búsquedas de recursos web que cumplan con su especificación de atributos. 3.5
SERVICIOS DE ARCHIVOS EN RED.
Los servicios de archivos de red hacen posible la colaboración en el desarrollo de documentos y proyectos. Cada miembro de un equipo de proyecto puede hacer contribuciones a un documento o proyecto a través de un servicio de archivos de red compartido. Además de compartir archivos de computadora, las redes permiten a los usuarios compartir dispositivos de impresión. Los servicios de impresión de la red pueden hacer accesible una impresora de alta velocidad a muchos usuarios. Esta impresora opera como si estuviera directamente conectada a computadoras individuales. La red puede enviar solicitudes provenientes de muchos usuarios a un servidor de impresión central donde estas solicitudes se procesan. Múltiples servidores de impresión, cada uno de ellos ofreciendo una diferente calidad de salida, puede implementarse de acuerdo a los requisitos de los usuarios. Bajo control administrativo, los usuarios pueden seleccionar el servicio que necesitan para un trabajo en particular. De esta forma, las redes proporcionan un uso más eficiente de los costosos dispositivos de impresión sin duplicación. Todos los sistemas operativos de red ofrecen servicios de archivos e impresión. Compartir información, colaborar en proyectos y proporcionar acceso a dispositivos de entrada y salida son servicios comunes de las redes de computadoras. Los usuarios de una red pueden compartir más que información y dispositivos especiales. También pueden compartir aplicaciones, como programas de procesamiento de texto, que se instalan en el 1 servidor. Los usuarios pueden ejecutar aplicaciones compartidas desde un servidor sin utilizar espacio en sus discos duros locales para los archivos del programa.
3.6
REPLICACIÓN.
Algunos años atrás, la data de las empresas se encontraba almacenada en un repositorio central. Departamentos remotos accedían a la información que necesitaban por medio de conexiones directas al repositorio central, o por solicitudes de reportes impresos desde el Sistema de Información Gerencial (MIS – Managment Information System). Sin embargo, las conexiones eran costosas, poco fiables y limitadas en número de usuarios concurrentes, al mismo tiempo los reportes eran poco flexibles y su generación era lenta. Luego aparecieron sistemas abiertos de bajo costo en recursos de computación y de gran alcance a los diferentes departamentos remotos de la empresa. La posibilidad de compartir la base de datos de la empresa efectivamente y la utilización eficaz de los recursos se convirtieron en ventajas competitivas para las organizaciones. Hoy en día las empresas no se preguntan "¿Por qué distribuir y compartir los datos de la organización?" sino más bien, "¿Cómo se puede distribuir información de manera efectiva?". Como veremos a continuación, la replicación se está convirtiendo rápidamente en la mejor elección de arquitectura de aplicaciones distribuidas para la mayoría de las empresas.
Replicación Síncrona: Confirmación en dos fases
Este modelo de replicación apareció a finales de 1980, gracias a Sybase la empresa pionera en este campo. Éste ofrece una distribución y compartimiento de información de forma oportuna, y al mismo tiempo permite la sincronización de data distribuida en distintas ubicaciones. Bajo este modelo, una transacción será únicamente aceptada si todos los puntos interconectados (en diferentes locaciones) están de acuerdo con ello, que no es más que un mecanismo “handshake” que permite a las aplicaciones remotas
coordinar y confirmar cada transacción.
Replicación No basada en Transacciones: Tablas Instantáneas
Los primeros esfuerzos para hacer frente a la demanda de distribución de copias de los datos, se basaron en el uso de tablas instantáneas. La implementación de tablas instantánea permite la distribución asíncrona de los cambios en tablas individuales, en subconjunto de tablas o incluso en colecciones de tablas de acuerdo a un horario preestablecido. A pesar de ser un modelo más avanzado que la “Descarga y Carga”, el uso de tablas
instantáneas tiene varios inconvenientes considerables debido a que no mantiene la
integridad de las transacciones y solo provee una copia de sólo lectura que a su vez no puede ser actualizada por las diferentes unidades de negocio que las acceden. Replicación No basada en Transacciones: Triggers en Bases de Datos Además de las tablas instantáneas, los triggers son otro mecanismo asíncrono para el proceso de replicación de datos. Usualmente, se piensa en un trigger como una alarma de base de datos que está asociado a un dato en específico. Este modelo se basa en que cuando se realiza un cambio en los datos, se activa un trigger y este a su vez inicia el proceso de replicación de los datos específicos que fueron modificados que al mismo tiempo están asociados al trigger. A pesar de que este modelo ofrece mayor flexibilidad que las tablas instantáneas, no logra superar la falta de protección sobre la integridad de las transacciones. Además las limitaciones del modelo incluyen:
Replica datos individuales que hayan sido modificados pero no mantiene un registro de transacciones. Permiten la replicación en un solo sentido. Las réplicas de los datos en las diferentes locaciones son sólo de lectura y estas no pueden ser modificadas. La ejecución excesiva de triggers ocasiona una sobrecarga en la base de datos e impacta su rendimiento. Los triggers demandan una gestión cuidadosa y constante de los DBA.
UNIDAD IV
4
CONTROL DE CONCURRENCIA
4.1
CONCURRENCIA.
Esta característica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red. 4.2
CONTENCIÓN Y CONTROL DE LA CONCURRENCIA .
El control de concurrencia es necesario para mantener los recursos compartidos de varias transacciones lejos una de la otra. Como siempre, se puede considerar análogo el término de transacción con el de proceso, siempre y cuando su trabajo sea transaccional. Existen 3 mecanismos de control de concurrencia: Locks:
La granularidad del lock afecta el nivel de concurrencia (archivo, registro, pagina, renglón, etc) Antes de usar eun archivo se aplica un lock de escritura o lectura. Los locks de lectura no son exclusivos, se pueden tener más de uno en un mismo archivo. Los locks de escritura no permiten ningún otro tipo de lock mientras este se encuentre activo. Un lock de grano fino permite mayor paralelismo, pero es más caro, requiere de más cerraduras y es probable que ocurran bloqueos. Cada servidor administra los locks de sus propios datos. Los locks no pueden abandonarse hasta que la transacción haga COMMIT o ABORT en todos los servers involucrados Si los administradores del lock en diferentes servidores colocan sus locks independientemente, hay chances de tener un ordenamiento de transacciones diferente. Este orden diferente puede llevar a dependencias cíclicas entre las transacciones y una situación de deadlock distribuido. La adquisición y liberación en el momento en que se necesitan o se dejan de necesitar puede conducir a inconsistencias o deadlocks. Para evitar esto, se usan locks de 2 fases. Son llamados asi porque se dan dos fases distintas: la fase de crecimiento (en donde pide todos los locks que vaya a necesitar) y fase de contracción (que es donde libera todos los locks)
Usar locks de 2 fases en todas las transacciones garantiza que todos los esquemas de planificación formados mediante intercalación son perfectamente serializables. Existe en los servidores una tabla que mantiene una tabla sobre todos los locks de los datos del servidor. Otra variante del lock de 2 fases, es la variante estricta, en la cual la fase de contracción no se realiza hasta que la transacción haya hecho COMMIT o ABORT (esto trae aparejadas una serie de ventajas: una transacción siempre lee un valor commited, y que la adquisición y liberación de locks puede controlarse mediante el sistema, sin que la transacción se de cuenta. También se eliminan los abortos en cascada, ósea, deshacer una transacción commiteada) Los locks pueden provocar deadlocks (cada transacción espera que otra transacción termine, formando así un ciclo de espera). Para prevenir los deadlocks, se pueden hacer que todos los locks se pidan a la vez o que una vez que una transacción pide un lock de algo, no puede pedir de un lock de algo que sucede antes. Una manera simple de resolver los deadlocks, es incluir un timeout a cada lock, o hacer que transacciones hagan ABORT, hasta que se solucione el deadlock.
Control de concurrencia optimista:
Se asume que las transacciones van a completar sin afectarse entre si, y de esta manera continuar sin lockear los recursos que afectan Cada transacción mantiene un registro de los archivos escritos y los leídos. En el momento de hacer commit, se verifica con todas las demás transacciones para ver si alguno de los archivos fue modificado desde el inicio de la transacción. Si fue asi, hace ABORT. Sino, COMMIT. Las validaciones de todas las transacciones tiene lugar durante la primer fase del protocolo 2 phase commit. Por este esquema, no existen los deadlocks. Brinda paralelismo máximo ya que no hay que esperar nada. Su única desventaja es que a veces falla (la probablididad de fallas crece al crecer la carga de las operaciones) y la transacción debe ejecutarse de nuevo.
Timestamping (TM):
Se le asocia a cada transacción una marca de tiempo en el momento que se hace el BEGIN TRANSACTION (la manera de identificar inequívocamente en un sistema distribuido es usando PID + TM) Mediante el algoritmo de Lamport podemos garantizar que los TM son únicas.
4.3
Cada archivo del sistema tiene asociado marcas de tiempo para la lectura y para la escritura, las cuales representan últimas transacciones con su TM que modificó o leyó ese archivo. Cuando un proceso quiere entrar a un archivo compara su TM con la del archivo. Si es mayor, no pasa nada. Si es menor, significa que alguien lo modifico y hace ABORT. Es similar al control de concurrencia optimista, salvo que aca no nos preocupa que las transacciones concurrentes usen los mismos archivos, siempre que la transacción con el número más chico lo haga primero. No tiene deadlock ya que al encontrar un problema aborta. TRANSACCIONES.
Los sistemas distribuidos son muy confiables debido a la posibilidad de brindar redundancia y autonomía de recursos en diferentes nodos, esto posibilita detectar y localizar fallas, sin embargo tenemos varios aspectos que representan problemas para la integridad de los recursos y que a su vez motivan el uso de transacciones
Dificultad para mantener consistencia en los datos Una misma vía de comunicación no siempre puede ser utilizada para suministrar interacción entre dos procesos Requerimientos de procesamientos en paralelo Manejo interactivo de uno o más usuarios
Sus Aplicaciones:
Base de datos Base de datos distribuidas Sistema de archivos distribuidos Desarrollo de aplicaciones tolerantes a fallos
Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento de los datos de las aplicaciones y que dependían de la consistencia de la información almacenada. Las transacciones son mecanismos que ayudan a simplificar la construcción de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y sincronizar operaciones como:
Operaciones de comparación de datos Aseguramiento de la seriabilidad de las transacciones con otras Atomicidad en su comportamiento
Recuperación de fallas
La palabra transacción describe una secuencia de operaciones con uno o más recursos que transforman su estado actual en un nuevo estado de consistencia. Es un conjunto de operaciones sobre datos que son tratadas como una unidad. Una transacción puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente. Dentro del área de los sistemas computacionales el concepto de transacciones fue inicialmente utilizado para definir la consistencia entre múltiples usuarios en una base de datos. Una transacción es una colección de operaciones que hacen transformaciones consistentes de los estados de un sistema conservando la consistencia del sistema. Una base de datos está en estado consistente si cumple todas las restricciones de integridad definidas sobre ella. Los cambios de estado se dan debido a actualización, inserción y eliminación de la información. Se quiere asegurar que la base de datos no entre en un estado de inconsistencia, pero durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. Lo importante aquí es asegurar que la base de datos vuelva aun estado consistente al concluir la ejecución de una transacción.
Propiedades de las transacciones Atomicidad: Una transacción es tratada como una unidad de operación. Por lo tanto todas las acciones de la transacción se llevan a cabo o ninguna de ellas se realiza .La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. Se efectúan todas las transacciones, pero en caso de fallas no se realiza ninguna. Una transacción debe concluir comprometida o abortada. En el caso del compromiso se instalan todas las actualizaciones y en el aborto se descartan todas las actualizaciones. Consistencia: Una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica. Gracias a esto, las transacciones no violan las reglas de integridad de una base de datos. Aislamiento: Durante la ejecución de una transacción, esta no debe revelar sus resultados a otras transacciones concurrentes antes de su compromiso. Si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado en forma secuencial (Seriabilidad). La seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado. Durabilidad: Es la propiedad de las transacciones que asegura que una vez que una transacción realiza su compromiso, sus resultados son permanentes y no pueden ser borrados de la base de datos, se asegura que los resultados de una transacción sobrevivirán a fallas del sistema. Las transacciones brindan una ejecución atómica y confiable en presencia de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y un manejo correcto de réplicas (en el caso que se soporten). 4.4
TRANSACCIONES ANIDADAS.
Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transacción de nivel superior puede producir hijos (subtransacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.
En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Una transacción anidada dentro de otra conserva las mismas propiedades que las de su padre, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que él. El compromiso de una subtransaccion es condicional al compromiso de su padre, si el padre de una o varias subtransacciones aborta, las subtransacciones hijas también serán abortadas. Las transacciones anidadas brindan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transacción. Así también, es posible recuperarse de fallas de forma independiente de cada subtransaccion. Esto limita el daño a una parte más pequeña de la transacción, haciendo que el costo de la recuperación sea el menor. También se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser leído antes de que pueda ser escrito entonces se tendrán transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos 4.5
BLOQUEOS.
Un bloqueo en general es cuando una acción que debe ser realizada está esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevención, detección, y recuperación. También es necesario considerar factores como que hay sistemas en los que permitir un bloqueo es inaceptable y catastrófico, y sistemas en los que la detección del bloqueo es demasiado costosa. En el caso específico de las bases de datos distribuidas usar bloqueo de recursos, peticiones para probar, establecer o liberar bloqueos requiere mensajes entre los manejadores de transacciones y el calendarizador. Para esto existen dos formas básicas:
Autónoma: cada nodo es responsable por sus propios bloqueos de de recursos. Una transacción sobre un elemento con n replicas requiere 5n mensajes Petición del recurso Aprobación de la petición Mensaje de la transacción
4.6
Reconocimientos de transacción exitosa Peticiones de liberación de recursos
Copia Primaria: un nodo primario es responsable para todos los bloqueos de recursos Una transacción sobre un elemento con n copias requiere n mensajes Una petición del recurso Una aprobación de la petición n mensajes de la transacción n reconocimientos de transacción exitosa Una petición de liberación de recurso
MARCAS DE TIEMPO.
Una marca de tiempo es un identificador único que el SGBD crea identifica una transacción por lo regular los valores de marca de tiempo se asigna en el orden en que las transacciones se introducen en el sistema. Una marca de tiempo puede considerarse como el tiempo de inicio de una transacción nos referimos a la marce de tiempo de una transacción T como MT (T) las técnicas para el control de concurrencia basadas en marcas de tiempo no usan bloqueos, por tanto no puede haber bloqueos mortales. Las marcas de tiempo se pueden generar de diversas maneras una posibilidad consiste en usar un cantador que se incremente cada vez que su valor se asigna a una transacción las marcas de tiempo de las transacciones están numeradas 1,2,3…. Un cantador de computador tiene un valor máximo finito por lo que
el sistema deberá restablecer periódicamente a cero el contador cuando haya un lapso corto en el que ninguna transacción se esté ejecutando otra forma de implementar las marcas de tiempo consiste en emplear el valor actual del reloj del sistemas y asegurar que no se generen dos valores de marca de tiempo antes de que el reloj rel oj cambie En lugar de determinar el orden entre las transacciones en conflicto en función del momento del acceso a los elementos, determinan por adelantado una ordenación de las transacciones. El interbloqueo es imposible. Una marca de tiempo es un identificador único asociado a cada transacción. Las actualizaciones físicas se retrasan hasta la confirmación de las transacciones. No se puede actualizar ningún elemento actualizado por otra transacción más reciente.
UNIDAD V
5
CONTROL DE ERRORES
5.1
CASOS DE FALLAS.
Una características de los sistemas distribuidos, que los difiere de los sistemas regulares, es la noción para errores parciales un error parcial puede ocurrir cuadro alguna componente del sistema distribuido falla puede afectar el correcto funcionamiento de algunos componentes, pero a la vez dejar otros componentes sin afectarlos. A contrario de un sistema mono usuario, el cal puede afectar a todo el sistema Un punto importante del sistema distribuido, es construirlos de tal forma que puedan recuperarse automáticamente del fallo sin afectar los rendimientos. 5.1.1 FALLAS LOCALES.
Una falla local sólo afecta a la transacción en la cual se presentó esa falla, como por ejemplo un overflow. Tales fallas son recuperables mediante los mecanismos de soporte de la instrucción COMMIT. Una falla global afecta a varias transacciones (y con mucha probabilidad a la totalidad) de las transacciones que se estaban efectuando en e momento de la falla. Tales fallas se dividen en dos tipos: Fallas del sistema, (por ejemplo interrupciones del suministro de electricidad) las cuales afectan a todas las transacciones que se están realizando pero no dañan físicamente a la base de datos. Falla de los medios de almacenamiento (por ejemplo, un aterrizaje de cabezas en el disco), las cuales si causan daños a la base de datos o a una porción de ella, y afectan al menos a las transacciones que están utilizando esa porción. 5.1.2 FALLA DE SITIO. Suponga que el coordinador falla antes de escribir el registro “compromiso”. En la recuperación, el coordinador difunde el mensaje “abortar” a todos los subordinados.
Todos los subordinados que estaban de acuerdo con el compromiso simplemente deshacen la transacción utilizando el registro deshacer y abortan. Otros subordinados solamente abortarán la transacción. Note que todos los subordinados se bloquean mientras no reciban el mensaje “abortar”. Suponer que el coordinador falla después de escribir el registro “compromiso” pero antes de escribir el registro “completo”. En la recuperación, el coordinador difunde el mensaje “compromiso” a todos los subordinados y espera el reconocimiento. En este
caso también los subordinados se bloquean mientras no reciban el mensaje “compromiso”. Suponer que el coordinador falla después de escribir el registro “completo”. En la
recuperación, no hay nada que pueda ser hecho por la transacción. Si un subordinado falla en la fase 1, el coordinador puede abortar la transacción porque no recibe ninguna respuesta del subordinado fallido. Suponer que un subordinado falla en la fase 2, esto es, después de escribir los registros deshacer y rehacer. En la recuperación, el subordinado debe consultar con el coordinador si debe abortar (es decir, si debe ejecutar una operación deshacer) o comprometer la transacción. Note que el comprometer significa realizar una operación rehacer porque el subordinado pudo fallar antes de actualizar la base de datos. En el caso de falla en la transmisión de mensajes, el protocolo de dos fases perderá mucho tiempo enviando mensajes y posiblemente la transacción no se ejecute. El protocolo de compromiso de dos fases garantiza la atomicidad global, su principal desventaja es que es un protocolo con bloqueo, existe otro protocolo de compromiso sin bloqueo el cual se sale del alcance de este material. 5.1.3 FALLAS DEL CANAL DE COMUNICACIÓN.
Una falla de un medio de comunicación, ocurre cuando un sitio no puede comunicarse con otro sitio operacional de la red. Esto es ocasionado por la falla del nodo de conmutación y/o por los enlaces de comunicación del sistema. La falla de un nodo de conmutación incluye la falla del sistema y la falla de almacenamiento secundario, por otro lado, la falla de enlace incluye una ruptura física y ruido en los canales de comunicación. Note que una falla en un medio de comunicación (esto depende de la topología y la conectividad) puede no causar la pérdida total de las facilidades de comunicación. Por ejemplo, una falla en el medio de comunicación puede simplemente causar una pérdida del mensaje, la recepción de un mensaje con algunos errores, o la partición de una red donde un segmento de sitios pueden ser incomunicados con los sitios en otro segmento, aunque los sitios dentro de un segmento pueden comunicarse entre sí. 5.2
PROTOCOLOS DE RECUPERACIÓN.
Protocolos REDO/UNDO Recuperación in-place Dado que las actualización in-place hacen que los valores anteriores se pierdan, es necesario mantener suficiente información de los cambios de estado en la base de datos. Esta información puede incluir entre otras cosas:
Identificador de la transacción, Tipo de operación realizada, Los datos accesados por la transacción para realizar la acción, El valor anterior del dato (imagen anterior), El valor nuevo del dato (imagen nueva).
Operación de REDO: utiliza la información del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. genera una nueva imagen. Operación UNDO: restablece un dato a su imagen anterior utilizando la información del registro de la base de datos. No Undo/No Redo. Parece una paradoja pero realmente estos algoritmos solo son
implementables mediante las técnicas de actualización por sombreo, manteniendo dos tablas de direcciones de páginas: (a)Tabla de preimágenes y (b)Tabla de páginas sombra (Postimágenes). El COMMIT llevará a dar por buena la tabla de direcciones de páginas sombra, mientras que la cancelación de la transacción equivaldrá a mantener la tabla de direcciones original. El coste de cualquiera de las operaciones equivale a manejar dichas tablas puesto que las páginas sucias ya fueron descargadas a nuevas direcciones. 5.3
PROTOCOLOS DE RECUPERACIÓN DISTRIBUIDOS.
La recuperación de fallas en un DDBMS es más complicado que las de un DBMS por:
Aparecen nuevas clases de fallas: una falla de comunicación y la falla de algún sitio que se encontraba ejecutando una subtransacción. Todas las transacciones llegan al commit o no lo hacen, sin importar fallas de comunicación o de la localización de un sitio. Esto es garantizado al usar un protocolo de commit.
Durante la ejecución normal cada sitio mantiene su log, y las acciones de las subtransacciones son logged en el sitio donde son ejecutadas. El manejador de transacciones en el sitio donde ésta se originó es llamado el coordinador para la transacción, los manejadores de transacciones en los sitios donde las subtransacciones se ejecutan son llamados subordinados (con respecto al coordinador de esa transacción). Protocolo de Dos Fases: Cuando el usuario decide hacer commit en una transacción, el comando de commit es mandado al coordinador para la transacción. Los pasos son los siguientes: 1. El coordinador manda un prepárense a cada subordinado. mensaje Protocolo de Tres fases
2. Cuando el subordinado recibe el mensaje prepárense, decide si abortar o hacer commit en su subtransacción. Él fuerza la escritura de un abort o preparado en el log, y luego manda un mensaje de si o no al coordinador. 3. Si el coordinador recibe un mensaje de si de todos los subordinados, fuerza la escritura del commit en los registros del log y luego manda un mensaje de commit a todos los subordinados. Caso contrario o algunos de los subordinados no responde en intervalo de tiempo específico, fuerza la escritura de abort en el log, y manda un mensaje de aborten a los subordinados. 4. Cuando un subordinado abort este fuerza la escritura de abort en el log, y manda un mensaje de ack al coordinador, y aborta la subtransacción. Cuando un subordinado commit fuerza la escritura de commit al log, y manda un mensaje de ack al coordinador, luego hace commit con su transacción. 5. Finalmente el coordinador recibe todos los ack de sus subordinados y escribe en el log end para la transacción. Reinicio luego de una falla: Al momento de hacer una recuperación se aplican los siguientes pasos: *Si tenemos un commit o un abort de la transacción T, limpiamos la transacción, aplicamos REDO o UNDO (según el caso). Si este sitio es el coordinador, el cual puede determinar los commits y los aborts a partir del log, debemos periódicamente reenviar un commit o un abort a cada subordinado hasta que recibamos un ack. Después de recibidos los acks de todos los subordinados, se escribe un end en el log para T. Si nos preparamos para escribir en log para la transacción T, pero esta no a enviado ni commit ni un abort; entonces este sitio es subordinado, y el coordinador puede estar determinado para preparado para grabar en el log. Debemos repetidamente contactar al coordinador del sitio y determinar el estatus de T. Una vez que el coordinador responda con cualquiera de las dos commit o abort, escribimos el correspondiente registro log, aplicamos EDO o UNDO (según sea el caso) y escribimos end de la transacción en el log.
UNIDAD VI
6
ESCENARIOS DE APLICACIÓN
6.1
CORBA.
En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información. CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existe para Ada, C,C++, Smalltalk, Java, Python, Perl y Tcl. Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto. CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware. La OMG El Object Management Group (OMG) es responsable de la definición de CORBA. El OMG comprende más de 700 empresas y organizaciones, incluyendo casi todos los principales fabricantes y desarrolladores de tecnología de objetos distribuidos, incluyendo la plataforma, base de datos y proveedores de aplicaciones, así como de herramientas de software y desarrolladores Permite invocar métodos de objetos remotos sin que importe el lenguaje en el que estén escritos el llamador y el llamado, ni las plataformas (s.o. y hw.) y redes de comunicación intermediasn Incluye un buen número de servicios:
Nombres Trading Seguridad Transacciones Persistencia
Notificaciones Etc.
Está estandarizado por el OMG (Object Management Group) Que es el mayor consorcio de la industria del software, sólo emite especificaciones (no existe implementación de referencia), las especificaciones se desarrollan por consenso y son públicas y gratuitas, existen muchos fabricantes que implementan las especificaciones más importantes para las plataformas más usuales, también estandariza UML (Unified Modeling Language) De sus Principales Ventajas (con respecto a otras tecnologías similares) se encuentran:
Software COTS (Commercial Off The Shelf) Estandarizado, múltiples implementaciones (no se depende de un fabricante) Las especificaciones se adoptan por consenso Buena infraestructura para construir aplicaciones distribuidas Permite integrar aplicaciones heterogéneas
Desventajas
6.2
No es la tecnología más sencilla de utilizar las especificaciones tardan en desarrollarse, y en consecuencia las implementaciones tardan en salir al mercado. SISTEMA OPERATIVO MATCH.
Mach es un proyecto de diseño de sistemas operativos iniciado en la Universidad Carnegie Mellon con el objetivo de desarrollar un micro núcleo. Mach es un núcleo de sistema operativo desarrollado en la Carnegie Mellon University (CMU) para soportar la investigación de sistemas operativos, principalmente computación distribuida y paralela. El proyecto en CMU se ejecutó desde 1985 hasta 1994. Mach se desarrolló con la premisa de que todos los sistemas operativos modernos comparten una serie de características en común, o son deseadas si es que no las tienen aún. Éstas incluyen: Soporte para múltiples aplicaciones usando multitarea.
Hilos, los cuales pueden ser pensados como las partes de una aplicación, o miniaplicaciones cuando hay multitarea. Soporte multi-procesadores, en una máquina única o sobre una red. Comunicaciones interprocesos, enviando mensajes directamente entre aplicaciones. Protección y seguridad de memoria. Por la época, a inicios de la mitad de los '80, varios proyectos estuvieron intentando resolver uno de estos problemas. Esto típicamente significó tomar un sistema operativo existente – a menudoBSD (UNIX)- modificando partes del mismo. Después de cada modificación el sistema operativo era compilado, la máquina reiniciada, y se probaba el nuevo cambio. Había una serie de problemas con este enfoque, incluso los más insignificantes errores causarían que la máquina entera se colgara. Mach explora el concepto al que ahora nos referimos como micronúcleo. En vez de tener todo el código para el sistema operativo en un gran programa único (llamado núcleo), la mayoría del código estaría ubicado en programas más pequeños conocidos como servidores, los cuales se ejecutarían como cualquier otro programa. El trabajo del núcleo se reduce esencialmente en "ser" el sistema operativo, a mantener los servidores y programar su acceso al hardware. En teoría esto significa que los cambios al S.O. requerirían nada más que una recarga de ese único programa servidor, concepto opuesto a reconstruir el Sistema Operativo y reiniciar la máquina. Solo trabajar en el núcleo Mach en sí mismo requeriría un reinicio, y en teoría eso debería ser un hecho inusual. Mach no es un sistema operativo en sí mismo, y es bastante inútil sin un conjunto de servidores (estos servidores no existen). De modo que para obtener un sistema útil y ejecutándose, los autores de Mach portaron el Unix BSD al núcleo Mach de forma rápida y simple: en vez de separar BSD en distintas partes y construir cada una de ellas como un servidor, simplemente compilaron el núcleo entero en un servidor y lo ejecutaron. El resultado era conocido como POE. Con POE ejecutándose (efectivamente) entre las otras aplicaciones, el rendimiento fue pésimo. Cada llamada de una aplicación de usuario, digamos para obtener la hora, requería que el mensaje fuera enviado al núcleo (una operación simple conocida como cambio de contexto), el cual enviaría el pedido a la librería Unix con otro cambio de contexto y luego repetir todo de nuevo para la respuesta... Sin embargo, Mach, a pesar de que no era un fallo propio, era considerado muy poderoso, pero increíblemente lento. Durante la década siguiente, el trabajo se orientó a mejorar el funcionamiento de estos mensajes varias veces, hasta el punto de que el rendimiento de estos sistemas operativos
basados en Mach fuera a menudo mejor que el de los BSD en los que estaban basados. Sin embargo por ese tiempo el mundo académico había perdido en gran parte interés en la investigación de SSOO, y la promesa de Mach's siguió sin cumplirse. A finales del siglo XX se ha pensado que el Mach asumiría lentamente el control del universo entero de sistemas operativos, pero esto no ha sucedido. Quizás la razón más grande del fracaso de Mach puede ser la "holgazanería": a todos les parecía que era el trabajo de otro entregar la biblioteca basada en el SO, y no lo hizo nadie. El esfuerzo más grande hasta la fecha es GNU Hurd, pero GNU Hurd está ahora alrededor de una década de atraso. Varios sistemas operativos propietarios han sido más acertados, incluyendo QNX que parece cumplir todas las promesas de Mach. El trabajo sobre Mach se llevó durante varios años en la CMU, para quedar finalmente inactivo cuando muchos de los desarrolladores dejaron la academia para trabajar en la industria. El Mach fue brevemente revivido en la Universidad de Utah a mediados de los 90s y produjo el Mach 4 (http://www.cs.utah.edu/flux/mach4/html/Mach4-proj.html) que tenía mejoras significativas, antes de otra vez volverse inactivo. Mientras tanto varios vendedores tomaron enfoques prácticos para usar Mach. La capa del BSD (y otras) fue ejecutada directamente dentro del núcleo (lo que evita así intercambios de contexto) lo que dio lugar a un rendimiento razonable mientras que todavía conservaba las ventajas del multi-procesamiento y de un modelo de hilos fácil de usar. Sin embargo incluso estas ventajas se han erosionado tanto como el hecho de que varios vendedores de Unix que han trabajado para proporcionarlas en sus propios productos. Los sistemas operativos basados en este concepto del Mach fueron OSF/1, NeXTSTEP, e IBM OS/2 para las máquinas basadas en RS/6000 – ninguno de los cuales es ya usado ampliamente -. Otros sistemas operativos querían migrar a esta clase de sistema también, como Pink de Apple, Workplace OS de IBM y varios más. 6.3
RMI (Java Remote Method Invocation).
Es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI. RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto. La invocación se compone de los siguientes pasos:
6.4
Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java). Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta. Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente. El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local. INFORMÁTICA DISTRIBUIDA.
La generalización de las redes de banda ancha de alta velocidad y el aumento constante de la potencia informática han cambiado la gestión de la información y los servicios de información. Recursos geográficamente distribuidos, tales como bancos de datos y superordenadores, están interconectados y son un recurso unificado y único que se puede utilizar en todo el mundo. Se observa una tendencia creciente a subcontratar tareas informáticas repetitivas o que consumen muchos recursos a proveedores de servicios, y está apareciendo un nuevo paradigma en el que se ofrecen servicios de capacidad informática. Las empresas ya no necesitan realizar personalmente todo su trabajo informático, ya que los datos se pueden procesar y los software se pueden almacenar a distancia en una "nube", y grandes redes de ordenadores pueden formar una "malla" que representa una potencia considerable. El objetivo de los sistemas informáticos distribuidos es conectar a usuarios y recursos de manera transparente, abierta, rentable, fiable y adaptable. Los recursos físicos se pueden compartir, al igual que los virtuales, tales como sistemas operativos, tareas y aplicaciones. Conectarse a la nube
En general, la nube se puede comparar con un sistema de suministro eléctrico que se extiende en zonas muy extensas, constituye una sola entidad y abastece en electricidad a millones de aparatos y consumidores. Las distintas partes son propiedad de organizaciones diferentes, que las explotan, y los usuarios suelen desconocer los detalles operacionales o la ubicación de los recursos que utilizan.
Empresas de tecnología y de Internet, tales como Google, Amazon, Microsoft y otras, han adquirido conocimientos considerables en la explotación de grandes centros de datos. Sus conocimientos se extienden a los software de gestión de procesos y de inteligencia empresarial, así como otras aplicaciones, tales como motores de búsqueda Internet, mapas, y correo electrónico. En la informática en nube, todas esas aplicaciones residen en un centro de datos y se ofrecen comercialmente como "software como servicio" (SaaS). Los usuarios ya no necesitan instalarlos en su sistema. De este modo se ahorran gastos de licencia y los costes de mantenimiento y actualización de programas. Para las pequeñas y medianas empresas, la posibilidad de subcontratar también puede facilitar su participación en numerosas actividades que exigen una gran capacidad de cálculo, ya que suprimen las necesidades de inversión. Incluso algunas grandes empresas han adoptado soluciones en nube, dado el aumento de la capacidad de los proveedores de servicios, y de las posibilidades que ofrecen. Otra solución consiste en subcontratar determinadas tareas a la nube, tales como el filtrado de correos indeseados y virus, y conservar otras en el centro de datos de la empresa, tales como el almacenamiento de material confidencial. Ahora bien, para aprovechar la informática en nube, es necesario poder acceder a conexiones de banda ancha fiables con Internet. Esto no siempre es posible en los países en desarrollo, que afrontan dificultades tales como el coste elevado de los software y equipos, tendidos eléctricos poco fiables y un acceso limitado a la banda ancha. Si bien el número de abonados a Internet de banda ancha ha aumentado rápidamente en todo el mundo, sigue habiendo grandes diferencias. La banda ancha ubicua y de tarifa plana es una de las condiciones más importantes del éxito de la informática en nube. Una nube inquietante
También hay otras dificultades. Para que este paradigma tenga éxito se han de solventar asuntos de privacidad, seguridad, responsabilidad, acceso y reglamentación. Fiabilidad y responsabilidad: Los usuarios esperan que la nube, como todos los demás servicios de telecomunicaciones, sea un recurso fiable (especialmente si se utiliza para aplicaciones "fundamentales para la misión"), y esperarán también una clara indicación de las responsabilidades si se produce un problema grave. La integridad y la precisión de los datos son otros aspectos de la fiabilidad. Resultados erróneos, o la pérdida o alteración de los datos, pueden tener graves consecuencias para el usuario de la nube. Los acuerdos de servicio deben tener en cuenta estas consideraciones. Seguridad, privacidad, anonimato: Al compartir la infraestructura física, los usuarios disfrutan de niveles de privacidad y anonimato inferiores a los de los usuarios de aplicaciones de sobremesa. Para proteger la privacidad, se han de proteger
cuidadosamente los datos de los usuarios (incluida la información sobre los clientes), así como las aplicaciones que manipulan esos datos. Limitaciones de acceso y utilización: El almacenamiento y la divulgación de los datos a través de una nube también pueden plantear problemas de derechos de autor, licencias y propiedad intelectual. Cualquier usuario que disponga de una conexión Internet puede acceder desde cualquier lugar y en todo momento a una nube, pero las licencias, los acuerdos de utilización y los derechos de propiedad intelectual pueden ser diferentes en cada país. Los gobiernos deberán estudiar las políticas y reglamentaciones apropiadas para obtener una protección adecuada. Por ejemplo, podría ser obligatorio que los acuerdos de servicio entre usuarios y proveedores incluyeran disposiciones tales como:
Umbrales básicos de fiabilidad Asignación de responsabilidad por la pérdida o violación de datos Expectativas de seguridad de los datos Protección de la privacidad Expectativas de anonimato Derechos de acceso y utilización.
Los proveedores de informática distribuida y los poderes públicos deben estudiar estas consideraciones para fomentar la confianza. Conectarse a una malla
La informática en malla es otra posibilidad de aprovechar recursos distribuidos. En lugar de utilizar centros de datos, este método recurre a una inmensa "malla" de máquinas que, individualmente, pueden ser apenas tan potentes como un ordenador doméstico ordinario. La informática en malla es ideal para resolver problemas de ciencias, ingeniería y comercio que exigen muchos recursos. Por ejemplo, en el sistema Enabling Grids for E-sciencE (EGEE), uno de los más grandes del mundo, se utilizan 80.000 unidades de procesamiento centrales (CPU). Más de 10.000 usuarios de 140 instituciones en 50 países producen juntos un recurso informático fiable y adaptable que está a la disposición de los investigadores europeos y de todo el mundo. Los cuatro experimentos del Gran Colisionador de Hadrones del CERN, la Organización Europea para la Investigación Nuclear, envían cotidianamente más de 150.000 tareas a la infraestructura del EGEE, generando centenares de terabytes de datos al año. Esta malla también se utilizó para ayudar a la Conferencia Regional de Radiocomunicaciones de la UIT de 2006 a establecer un nuevo plan de frecuencias para introducir la radiodifusión digital en las bandas de ondas métricas y decimétricas. Los complejos cálculos exigían una gran capacidad informática en un plazo muy apretado. El Sector de Radiocomunicaciones de la UIT (UIT –R) empleó un sistema distribuido de 100 ordenadores de alta velocidad capaces de realizar 200 tareas en paralelo. Para
