Professional Documents
Culture Documents
Un sistema distribuido consta de varios procesadores. Estos se pueden organizar como coleccin de estaciones de trabajo personales, una pila pblica de procesadores o alguna forma hbrida. En todos los casos, se necesita cierto algoritmo para decidir cul proceso hay que ejecutar y en qu mquina. Para el modelo de estaciones de trabajo, la pregunta es cundo ejecutar el proceso de manera local y cundo buscar una estacin inactiva. Para el modelo de la pila de procesadores, hay que tomar una decisin 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 dems 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 situacin, el programa remote verifica la estacin de trabajo inactiva, la cual si continua libre se elimina as misma del registro y da la seal de continuar, de esta manera quien hizo la llamada puede enviar su ambiente e iniciar el proceso remoto. Modelo de pila de procesadores Este mtodo consiste en construir una pila de procesadores, repleta de CPU, en un cuarto de maquinas, los cuales se pueden asignar de manera dinmica a los usuarios segn la demanda. Desde el punto de vista conceptual este mtodo es mas parecido al tiempo compartido tradicional que al modelo de la computadora personal aunque se construye con la tecnologa moderna. La motivacin 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 pequeo numero de servidores de archivos para mayor economa, debe ser posible hacer lo mismo con los servidores de computo, es decir si colocamos todos los CPU en un gabinete de gran tamao en el cuarto de maquinas se pueden reducir los costos de suministro de energa y de empaquetamiento, lo cual produce un mayor poder de computo con una cantidad fija de dinero. De hecho convertimos todo el poder de cmputo en estaciones de trabajo inactivas a
las que se puede tener acceso de manera dinmica. Los usuarios obtienen tantos CPU como sea necesario, durante periodos cortos, despus de lo cual regresan a la pila, de modo que otros usuarios puedan disponer de ellos. Publicado por Mariangel 21 comentarios
Son correctos luego de intercambiar la informacin y de que todo se ha registrado. Son poco confiables mientras las tablas continan su actualizacin, es decir que se presentan situaciones de no equilibrio. Modelos de Asignacin Generalmente se utilizan las siguientes hiptesis: -Todas las mquinas son idnticas (o al menos compatibles en el cdigo); difieren a lo sumo en la velocidad. -Cada procesador se puede comunicar con los dems. Las estrategias de asignacin de procesadores se dividen en: -No migratorias: Una vez colocado un proceso en una mquina permanece ah hasta que termina. -Migratorias: Un proceso se puede trasladar aunque haya iniciado su ejecucin. Permiten un mejor balance de la carga pero son ms complejas. Los algoritmos de asignacin intentan optimizar algo: -Uso de las cpu: Maximizar el nmero de ciclos de cpu que se ejecutan para trabajos de los usuarios. Minimizar el tiempo de inactividad de las cpu. -Tiempo promedio de respuesta: Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta. -Tasa de respuesta: Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta mquina dividido por el tiempo que tardara en cierto procesador de referencia. Publicado por Mariangel 5 comentarios
de mensajes cada 200 milisegundos. Lo que se necesita es una forma de garantizar que los procesos con comunicacin frecuente se ejecuten de manera simultnea. Aunque es difcil determinar en forma dinmica los patrones de comn entre los procesos, en muchos casos, un grupo de procesos relacionados entre s iniciarn juntos. Por ejemplo, en general est bien suponer que los filtros de un entubamiento en UNIX se comunicarn entre s ms de lo qu lo harn con otros procesos ya iniciados. Supongamos que los procesos se crean en grupos y que la comunicacin dentro de los grupos prevalece sobre la comunicacin entre los grupos. Supongamos adems que se dispone de un nmero de procesadores lo bastante grande como para manejar al grupo de mayor tamao y que cada procesador se multiprograma con N espacios para los procesos multiprogramacin de nivel N). Publicado por Mariangel 4 comentarios
Tolerancia a Fallas
La promesa de los sistemas distribuidos slo se puede cumplir cuando a la base hardware adecuado se le aaden polticas y mecanismos tolerantes a fallas. El objetivo del diseo y construccin de sistemas tolerantes a fallas consiste en garantizar que el sistema contine funcionando de manera correcta como un todo, incluso en presencia de fallas. Se dice que un sistema falla cuando no cumple su especificacin. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podra provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de trfico areo, una falla podra ser catastrfica. Como las computadoras y los sistemas distribuidos se utilizan cada vez ms en misiones donde la seguridad es crtica, la necesidad de soportar las fallas cada vez es mayor. Un sistema consiste de un conjunto de componentes de hardware y software y son diseados para proveer un servicio especfico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempea estos servicios de la manera especificada. Un estado errneo en un sistema es un estado en el cual podra conducir a un fallo en el sistema. Un fallo es una condicin fsica anormal, las causas de un fallo incluyen: errores de diseo (como errores en la especificacin del sistema o en la implementacin), problemas de fabricacin, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagntica, 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 manifestacin de mal funcionamiento del sistema, el cual podra 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 recuperacin de un fallo, es un proceso que involucra la restauracin de un estado errneo a un estado libre de error. Publicado por Mariangel 4 comentarios
Transacciones, Definicin
Una transaccin es una coleccin 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 informacin. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecucin de una transaccin, 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 ejecucin de una transaccin 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. Publicado por Mariangel 3 comentarios
Coordinador de transacciones distribuidas de Microsoft (MS DTC) u otros administradores que admitan la especificacin Open Group XA del procesamiento de transacciones distribuidas. Para obtener ms informacin, consulte la documentacin de MS DTC. Una transaccin de una sola instancia de Database Engine (Motor de base de datos) que abarque dos o ms bases de datos es, de hecho, una transaccin distribuida. La instancia administra la transaccin distribuida internamente; para el usuario funciona como una transaccin local. En la aplicacin, una transaccin distribuida se administra de forma muy parecida a una transaccin local. Al final de la transaccin, la aplicacin pide que se confirme o se revierta la transaccin. El administrador de transacciones debe administrar una confirmacin distribuida de forma diferente para reducir al mnimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los dems revierten la transaccin. Esto se consigue mediante la administracin del proceso de confirmacin en dos fases (la fase de preparacin y la fase de confirmacin), que se conoce como confirmacin en dos fases (2PC). Fase de preparacin Cuando el administrador de transacciones recibe una solicitud de confirmacin, enva un comando de preparacin a todos los administradores de recursos implicados en la transaccin. Cada administrador de recursos hace lo necesario para que la transaccin sea duradera y todos los bferes que contienen imgenes del registro de la transaccin se pasan a disco. A medida que cada administrador de recursos completa la fase de preparacin, notifica si la preparacin ha tenido xito o no al administrador de transacciones. Fase de confirmacin Si el administrador de transacciones recibe la notificacin de que todas las preparaciones son correctas por parte de todos los administradores de recursos, enva comandos de confirmacin a cada administrador de recursos. A continuacin, los administradores de recursos pueden completar la confirmacin. Si todos los administradores de recursos indican que la confirmacin ha sido correcta, el administrador de transacciones enva una notificacin de xito a la aplicacin. Si algn administrador de recursos inform de un error al realizar la preparacin, el administrador de transacciones enva un comando para revertir la transaccin a cada administrador de recursos e indica a la aplicacin que se ha producido un error de confirmacin. Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar transacciones distribuidas a travs de Transact-SQL o de la API de base de datos.