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.
MODELO DE PILA DE PROCESADORES
Este método consiste en construir una pila de procesadores, repleta de CPU, en
un cuarto de maquinas, los cuales se pueden asignar de manera dinámica a los
usuarios según la demanda.
Desde el punto de vista conceptual este método es mas parecido al tiempo
compartido tradicional que al modelo de la computadora personal aunque se construye con la tecnología moderna. La motivación para la idea de la pila de procesadores
proviene de dar un paso mas adelante en la idea de las estaciones de trabajo sin disco. Si
el sistema de archivos se debe concentrar en un pequeño numero de servidores de archivos
para mayor economía, debe ser posible hacer lo mismo con los servidores de computo,
es decir si colocamos todos los CPU en un gabinete de gran tamaño en el cuarto de maquinas se pueden reducir los costos de suministro de energía y de
empaquetamiento, lo cual produce un mayor poder de computo con una cantidad fija de dinero.
De hecho convertimos todo el poder de cómputo en “estaciones de trabajo
inactivas” a las que se puede tener acceso de manera dinámica. Los usuarios obtienen tantos
CPU como sea necesario, durante periodos cortos, después de lo cual regresan a la
pila, de modo que otros usuarios puedan disponer de ellos.
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.
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.
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.
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.
No hay comentarios:
Publicar un comentario