MODELOS DE ASIGNACIÓN
Los algoritmos de asignación intentan optimizar algo:
Uso de las cpu:
Maximizar el número 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 máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
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.
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.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
PLANIFICACIÓN EN 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.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
Aunque es difícil determinar en forma dinámica los patrones de común entre los procesos, en muchos casos, un grupo de procesos relacionados entre sí iniciarán juntos.
TOLERANCIA A FALLAS
La promesa de los sistemas distribuidos sólo se puede cumplir cuando a la base hardware adecuada 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.
IMPORTANCIA EN LA COMUNIDAD DISTRIBUIDA
Una transacción es generalmente una unidad de trabajo que se hace a nombre de una aplicación o componente. Cada transacción puede estar compuesta de múltiples operaciones realizadas en datos que están dispersos en uno o varios procesos o en una o varias máquinas. Cada transacción asegura el trabajo de proteger la integridad del estado de un sistema al proveer cuatro garantías básicas conocidas como las propiedades ACID: atomicidad (atomicity), consistencia (consistency), aislamiento (isolation) y durabilidad (durability) y que se explican a continuación.
Una transacción tiene que ser atómica lo que significa que es indivisible; todas las operaciones deben ejecutarse o ninguna en lo absoluto. No debe haber posibilidad de que solo una parte se ejecute. En un sistema bancario, por ejemplo, una transferencia de dinero entre dos cuentas de cheques tiene que ser atómica; tomar dinero de una cuenta para agregarlo a otra. No es posible ejecutar una de las operaciones y la otra no. La atomicidad se garantiza a través de mecanismos de base de datos con los que se hace el seguimiento de la transacción. Si la transacción falla por cualquier razón, las actualizaciones que se hayan realizado hasta el momento serán deshechas. Solo si la transacción llega al fin los cambios se volverán parte de la base de datos. La propiedad de atomicidad permite escribir operaciones que emulan transacciones de negocio tales como retiros de cuentas de cheques, reservaciones de vuelo o compra y venta de bonos entre otras. Cada una de estas acciones, requiere actualizar varios datos y al implementarlas acciones en una transacción, se asegura que todas o ninguna de las actualizaciones se realizan. Aún más, la atomicidad garantiza que la base de datos se queda en un estado conocido después de la falla de una transacción lo que reduce el requerimiento de intervención manual. La terminación exitosa de una transacción se conoce como commit mientras que a la falla de una transacción se le conoce como abort.
Consistencia (Consistency). Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base de datos se encuentra en un estado consistente antes de ejecutar la transacción, una vez que ésta termine la consistencia de la base de datos deberá conservarse. Por consistente se debe entender, internamente consistente. En términos de base de datos esto significa que se satisfacen todas las restricciones en cuanto a su integridad que incluyen:
Todos los valores de la llave primaria son únicos.
La base de datos mantiene integridad referencial lo que significa que los registros solo referencian información que existe.
Ciertos predicados se mantienen. Por ejemplo, la suma de los gastos es menor o igual al presupuesto.
A diferencia de la atomicidad, el aislamiento y la durabilidad, la consistencia es una práctica de programación. La atomicidad, el aislamiento y la durabilidad están aseguradas estén o no programadas para preservar la consistencia. Es responsabilidad del desarrollador de la aplicación asegurar que su programa preserva la consistencia.
Aislamiento (Isolation). La tercera propiedad de una transacción es el aislamiento. Se dice que un conjunto de transacciones está aislado si el efecto del sistema que las ejecuta es el mismo que si ejecutara cada una a la vez; las transacciones se ejecutan en secuencia. Tómese, por ejemplo, el caso de un sistema bancario en el que dos transacciones intentaran hacer un retiro de los últimos $200 de una cuenta de cheques. Si se permite que al mismo tiempo, dos transacciones consulten el saldo antes de afectarlo, ambas determinarán que hay fondos suficientes y realizarán el retiro. En cambio, si las transacciones se ejecutan en serie -una detrás de otra-, solo una de las transacciones será capaz de retirar los últimos $200. La siguiente encontrará el saldo de la cuenta en cero. El usuario final tiene la percepción de que su transacción es la única en el sistema. La base de datos típicamente usa técnicas de locking o versioning en los datos que cada transacción accede. El efecto de esto es hacer que la ejecución parezca en serie aunque, internamente, el sistema ejecuta las transacciones en paralelo. Por la importancia y el impacto que tiene el aislamiento (isolation) en la escalabilidad, se le ha dedicado un capítulo completo de este libro.
Durabilidad (Durability). Cuando una transacción termina de ejecutarse, todas sus actualizaciones se graban en algún tipo de medio de almacenamiento, típicamente disco, en donde se asegura que las actualizaciones no se perderán. Aun si el sistema operativo falla, los resultados de la transacción son almacenados en disco y podrán ser encontrados ahí cuando se recupere el sistema operativo. Más aún, la durabilidad a menudo debe mantenerse por un periodo largo. Por ejemplo, por cuestiones de auditoria La durabilidad se obtiene por medio de un mecanismo que guarda en una bitácora (log) copia de todas las actualizaciones que una transacción realiza. Cuando se ejecuta el commit de la transacción, el sistema se asegura que todos los registros escritos en el log están en disco y entonces informa a la transacción que los resultados son durables. Si después del commit de la transacción y antes de escribirse a la base de datos, el sistema falla, es responsabilidad de éste reparar la base de datos lo que logra por medio de una lectura del log para verificar que se efectuó cada modificación hecha por una transacción committed. De no cumplirse esta condición, entonces vuelve a realizar las actualizaciones. Cuando esta actividad de recuperación se ha terminado, el sistema reanuda su operación normal. Cualquier nueva transacción encontrará un estado en la base de datos que incluye todas las actualizaciones. En resumen, las transacciones garantizan que los cambios al estado de un sistema se aplican atómicamente, dejan al sistema consistente, están aisladas una de otra mientras están en progreso y serán durables aun en casos de una falla catastrófica.
