Asignación de Procesos

ASIGNACIÓN DE PROCESADORES

Un sistema distribuido consta de varios procesadores. Estos se pueden organizar como colección de estaciones de trabajo personales, una pila pública de procesadores o alguna forma híbrida. En todos los casos, se necesita cierto algoritmo para decidir cuál proceso hay que ejecutar y en qué máquina. Para el modelo de estaciones de trabajo, la pregunta es cuándo ejecutar el proceso de manera local y cuándo buscar una estación inactiva. Para el modelo de la pila de procesadores, hay que tomar una decisión por cada nuevo proceso.

En cuarto lugar, cada maquina puede tener un sistema de archivos auto contenido, con la posibilidad de montarlo o tener su sistema de archivos de otras maquinas. La idea aquí es que cada maquina esta auto contenida en lo fundamental y que el contacto con el mundo exterior sea limitado. Este sistema proporciona un tiempo de respuesta uniforme y garantizada para el usuario y pone poca carga en la red.

Uso de estaciones de trabajo inactivas

Plantea el problema de encontrar estaciones de trabajo inactivas en la red que puedan ejecutar procesos. Por lo cual las estaciones de trabajo deben de anunciar cuando no cuentan con una carga de trabajo asignada, así todas las demás estaciones toman nota de esto y lo registran.

Ya sea que existan muchos o pocos registros, existe un peligro potencial de que aparezcan condiciones de competencia si dos usuarios llaman al mismo tiempo al comando remote y ambos descubren que la misma maquina esta inactiva, ambos intentaran iniciar procesos al mismo tiempo. Para detectar y evitar esta situación, el programa remote verifica la estación de trabajo inactiva, la cual si continua libre se elimina así misma del registro y da la señal de continuar, de esta manera quien hizo la llamada puede enviar su ambiente e iniciar el proceso remoto.

PLANIFICACIÓN DE LOS SISTEMAS DISTRIBUIDOS

No hay mucho que decir de la planificación en los sistemas distribuidos. Por lo general, cada procesador hace su planificación local (si tiene varios procesos en ejecución), sin preocuparse por lo que hacen los demás procesadores. Lo normal es que este método funcione. Sin embargo, si un grupo de procesos relacionados entre sí y con gran interacción se ejecutan en distintos procesadores, la planificación independiente no es el camino más eficiente.

La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro. El tiempo de cada procesador se comparte en pedazos de 100 milisegundos, donde A y C se ejecutan en los pedazos pares y B y D en los nones, como se muestra en la figura 4-20(a).

Supongamos que A envía muchos mensajes o lleva a cabo muchas llamadas a procedimientos remotos de D. Durante el tiempo 0, A inicia y llama de inmediato a D, que por desgracia no se ejecuta en ese momento, puesto que es el turno de C. Después de 100 milisegundos, se alternan los procesos, D obtiene el mensaje de A, lleva a cabo el trabajo y responde con rapidez. Puesto que B está ejecutándose, pasarán otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio de mensajes cada 200 milisegundos.

TOLERANCIA A FALLAS

La promesa de los sistemas distribuidos sólo se puede cumplir cuando a la base hardware adecuado se le añaden políticas y mecanismos tolerantes a fallas. El objetivo del diseño y construcción de sistemas tolerantes a fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en presencia de fallas.

Se dice que un sistema falla cuando no cumple su especificación. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podría provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.

Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.

Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.

TRANSACCIONES

Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción

Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.

Utilizacion e importancia de las transacciones en la comunicacion distribuida

Considere un banco que tiene tres sucursales, en cada sucursal, un ordenador controla las terminales de la misma y el sistema de cuentas. Cada computador con su sistema de cuentas local en cada sucursal constituye un "sitio" de la BDD; las computadoras están conectadas por la red. Durante las operaciones normales, las aplicaciones en las terminales de la sucursal necesitan sólo acceder la base de datos de la misma. Como sólo acceden a la misma red local, se les llaman aplicaciones locales.

Desde el punto de vista tecnológico, aparentemente lo importante es la existencia de algunas transacciones que acceden a información en más de una sucursal. Estas transacciones son llamadas transacciones globales o transacciones distribuidas.

La existencia de transacciones globales será considerada como una característica que nos ayude a discriminar entre las BDD y un conjunto de base de datos locales.

Una típica transacción global sería una transferencia de fondos de una sucursal a otra. Esta aplicación requiere de actualizar datos en dos diferentes sucursales y asegurarse de la real actualización en ambos sitios o en ninguno. Asegurar el buen funcionamiento de aplicaciones globales es una tarea difícil.

Los clientes manipulan el estado compartido a través de objetos que se ejecutan en servidores entre los que se reparte el trabajo. Uno de los beneficios que provee el modelo objeto-por-cliente es la simplificación del desarrollo mediante la eliminación del acceso concurrente a los objetos; el estado que forma parte del objeto está protegido implícitamente. Sin embargo, no alivia todas las preocupaciones que trae la concurrencia. Para coordinar el acceso al estado que un proceso o servidor mantiene para compartir entre todos los objetos, basta con usar técnicas tradicionales de acceso .NET o Win32 (i.e. critical sections, mutexes, etc.). Pero, ¿qué mecanismo se usar para coordinar el acceso concurrente al estado compartido que reside en la base de datos? La respuesta es: Transacciones.

Libros Relacionados

books.google.co.ve/books?id=W65mMwEACAAJ

books.google.co.ve/books?id=5mLqVqmVaS0C