You are on page 1of 6

Asignacin de Procesadores

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

Algoritmos o Modelos de Asignacin


Los algoritmos deterministas son adecuados cuando se sabe anticipadamente todo acerca del comportamiento de los procesos, pero esto generalmente no se da, aunque puede haber en ciertos casos aproximaciones estadsticas. Los algoritmos heursticos son adecuados cuando la carga es impredecible. Los diseos centralizados permiten reunir toda la informacin en un lugar y tomar una mejor decisin; la desventaja es que la mquina central se puede sobrecargar y se pierde robustez ante su posible falla. Generalmente los algoritmos ptimos consumen ms recursos que los sub-ptimos, adems, en la mayora de los sistemas reales se buscan soluciones sub-ptimas, heursticas y distribuidas. Cuando se va a crear un proceso se debe decidir si se ejecutar en la mquina que lo genera o en otra (poltica de transferencia): La decisin se puede tomar solo con informacin local o con informacin global. Los algoritmos locales son sencillos pero no ptimos. Los algoritmos globales son mejores pero consumen muchos recursos. Cuando una mquina se deshace de un proceso la poltica de localizacin debe decidir dnde enviarlo: Necesita informacin de la carga en todas partes, obtenindola de: Un emisor sobrecargado que busca una mquina inactiva. Un receptor desocupado que busca trabajo. Aspectos de la Implantacin de Algoritmos de Asignacin de Procesadores Casi todos los algoritmos suponen que las mquinas conocen su propia carga y que pueden informar su estado: La medicin de la carga no es tan sencilla. Un mtodo consiste en contar el nmero de procesos (hay que considerar los procesos latentes no activos). Otro mtodo consiste en contar solo los procesos en ejecucin o listos. Tambin se puede medir la fraccin de tiempo que la cpu est ocupada. Otro aspecto importante es el costo excesivo en consumo de recursos para recolectar medidas y desplazar procesos, ya que se debera considerar el tiempo de cpu, el uso de memoria y el ancho de banda de la red utilizada por el algoritmo para asignacin de procesadores. Se debe considerar la complejidad del software en cuestin y sus implicancias para el desempeo, la correctez y la robustez del sistema. Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno ms caro y ms complejo, generalmente ser mejor utilizar el ms sencillo. Se debe otorgar gran importancia a la estabilidad del sistema: Las mquinas ejecutan sus algoritmos en forma asncrona por lo que el sistema nunca se equilibra. La mayora de los algoritmos que intercambian informacin:

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

Planificacin De Sistemas Distribuidos


No hay mucho que decir de la planificacin en los sistemas distribuidos. Por lo general, cada procesador hace su planificacin local (si tiene varios procesos en ejecucin), sin preocuparse por lo que hacen los dems procesadores. Lo normal es que este mtodo funcione. Sin embargo, si un grupo de procesos relacionados entre s y con gran interaccin se ejecutan en distintos procesadores, la planificacin independiente no es el camino ms eficiente. La dificultad bsica 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 enva 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. Despus 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 ejecutndose, pasarn otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio

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

Aspectos relacionados al procesamiento de transacciones


Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones: 1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. 2. Consistencia de la base de datos interna. Los algoritmos de control de datos semntico tienen que satisfacer siempre las restricciones de integridad cuando una transaccin pretende hacer un commit. 3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. As tambin, se requieren protocolos para la recuperacin local y para efectuar los compromisos (commit) globales. 4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecucin de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. 5. Protocolos de control de rplicas. El control de rplicas se refiere a cmo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-onewrite-all (ROWA). Publicado por Mariangel 1 comentarios

Utilizacin de las Transacciones


Las transacciones distribuidas abarcan dos o ms servidores conocidos como administradores de recursos. La administracin de la transaccin debe ser coordinada entre los administradores de recursos mediante un componente de servidor llamado administrador de transacciones. Cada instancia de SQL Server Database Engine (Motor de base de datos de SQL Server) puede funcionar como administrador de recursos en las transacciones distribuidas que coordinan los administradores de transacciones, como el

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.

You might also like