El modelo de estación de trabajo
Consiste en un conjunto de estaciones de trabajo conectadas mediante una red local. En un momento dado, una estación de trabajo está ocupada o bien no está siendo utilizada por ningún usuario. Decimos entonces que está ociosa. Algunas estaciones de trabajo tienen disco y otras no tienen disco. Estas últimas conservan sus ficheros en el disco de otras estaciones, en las que ejecuta un servidor de ficheros. El servidor es accedido a través de la red local. Las ventajas del modelo de estaciones de trabajo son varias. Por una parte, cada usuario tiene una potencia de cálculo dedicada a él en exclusiva, lo que garantiza el tiempo de respuesta. Es posible utilizar aplicaciones gráficas sofisticadas, ya que tienen acceso directo a un hardware gráfico de altas prestaciones. Cada usuario tiene plena autonomía, de modo que puede utilizar los recursos de su máquina según su propio criterio. El modelo también presenta inconvenientes. Uno de ellos es el descenso continuado de los precios de los procesadores. Pronto será económicamente factible el que cada usuario disponga de diez CPU, e incluso cien. La pena es que deba adquirir cien estaciones de trabajo para aprovechar el precio del hardware. El otro es el de las estaciones de trabajo ociosas, ya que su potencia de cálculo es desaprovechada. Los recursos de cómputo no están bien gestionados. En ocasiones, algunos usuarios necesitan una estación más potente para ciertas aplicaciones mientras que si estas existen, tal vez estén ociosas. El primer problema, sin embargo, no es tal, ya que se soluciona construyendo estaciones de trabajo multiprocesador. Por ejemplo, a cada procesador puede asignársele los trabajos arrancados desde una ventana dada. Usando estaciones ociosas En las universidades este problema se acusa intensamente. En determinadas horas del día, casi todos los puestos de trabajo están ocupados y en ciertos periodos del año -que se ha observado coinciden con los plazos de entrega de prácticas- el número de puestos resulta claramente insuficiente. En otras horas y otras fechas, el número de estaciones ociosas es notorio. Este despilfarro de recursos ha preocupado a los investigadores, que han propuesto esquemas diversos a fin de paliar esta situación. El primer intento conocido de sacarle partido a una estación ociosa fue el mandato UNIX BSD rsh (de shell remoto). Se invoca como
cc% rsh maquina mandato
El primer parámetro es la dirección de red -típicamente una dirección IP- de una estación de trabajo y el segundo parámetro es el mandato que se desea ejecutar. La salida del mandato se redirige al terminal de emisión del mandato. El defecto de rsh es que el mandato es ejecutado por un shell que en general proporciona un entorno al mandato distinto al entorno local. En segundo lugar, es el usuario el que debe buscar una máquina ociosa, tal vez esperando que el dueño se vaya a tomar el bocadillo. Un tercer problema es que cuando el usuario vuelve se encuentra con que la máquina va más lenta, lo que con seguridad conduce a un cuarto problema, esta vez más acusado por el usuario que invocó rsh. La investigación en estaciones ociosas se ha centrado en la resolución de los siguientes problemas: 1. ¿Cómo encontrar una estación ociosa? 2. ¿Cómo puede un proceso ejecutar transparentemente? 3. ¿Qué ocurre si el dueño de la máquina ociosa vuele?
Buscando una estación ociosa Comencemos por el primer problema. Cabe antes preguntarnos ¿qué es una estación ociosa? En apariencia, es aquella sin un usuario cerca. Sin embargo, aun en tal caso, en un sistema actual ejecutan muchos procesos en “background”, como puede ser el demonio de impresión, de correo, de transferencia de ficheros y otros mil demonios. De todas formas, se suele considerar como ociosa una máquina que no tiene activo ningún proceso de usuario y cuyo teclado o ratón no han sido tocados durante varios minutos. Sea cual sea el critero para determinar cuándo una máquina está ociosa, los algoritmos para localizar una máquina ociosa son de dos tipos: servidores y clientes. Algoritmos servidores Se basan en un registro o base de datos de máquinas ociosas. Este registro se mantiene en una determinada máquina. Cuando una estación decide que está ociosa se dice que se convierte en un servidor de computación. En este momento envía un mensaje a la máquina que mantiene el registro, donde se abre una nueva entrada con la dirección y características de la nueva máquina ociosa. Cuando en una estación determinada un usuario decide ejecutar un mandato en una máquina ociosa, invoca el mandato remote, al que pasa como argumento el nombre de la aplicación o mandato que desea ejecutar:
cc% remote mandato
remote accede al registro para escoger una máquina apropiada. Algoritmos cliente Cuando se invoca remote, se difunde (esparcir) una petición diciendo qué programa se desea ejecutar, cuánta memoria necesita, si requiere o no un procesador de coma flotante, etc. Si todas las máquinas son iguales, esta información no es precisa, pero, en un entorno heterogéneo es esencial, por que no todos los programas pueden ejecutar en todas las máquinas. Cuando las réplicas de las máquinas ociosas llegan, remote elige una de ellas para ejecutar allí el programa. Una modificación útil es aquella en que cada estación ociosa retrasa el envío de la réplica en función de su carga de trabajo. La menos ocupada será la primera en enviar la réplica y será la máquina escogida. Ejecutando el programa en la máquina remota Encontrar una estación ociosa donde ejecutar un proceso es sólo el primer paso. La dificultad estriba (apoyar) en disponer en dicha máquina del mismo entorno de ejecución que en la máquina local (home workstation), de modo que el proceso ejecute de la misma forma en ambas. En la máquina remota, el proceso migrado necesita la misma vista del sistema de ficheros, el mismo directorio de trabajo y las mismas variables de entorno. Sólo después el proceso puede ejecutar. El problema que se plantea en una ejecución remota es el servicio de las llamadas al sistema. ¿Qué debe hacer el kernel, por ejemplo, para dar servicio a la llamada read? Depende de la arquitectura del sistema. Si las máquinas no tienen disco, sino que confían en un servidor de disco, todas las lecturas son redirigidas al servidor de disco, de la misma forma que se hubiese hecho en la máquina local. En el lado opuesto, si todas las máquinas tienen disco, la petición debe ser redirigida a la máquina local (home workstation). Otras llamadas como sbrk, que realiza una modificación del tamaño del segmento de datos del proceso, necesariamente deben ser servidas localmente. Lo mismo ocurre a llamadas que solicitan el estado de la máquina así como información acerca de la misma como su dirección de red, la memoria de que dispone, etc. Las llamadas al sistema que tratan con el tiempo son problemáticas por que las máquinas local y remota no están generalmente sincronizadas. Si usamos el tiempo de la estación remota puede introducir inconsistencias como vimos en el programa make. Si usamos el tiempo de la máquina local (home workstation) el retraso que provoca la comunicación también es fuente de problemas. En fin, aunque ejecutar procesos en máquinas remotas es posible, es un asunto complejo. El usuario vuelve Una estación de trabajo es una máquina personal. El hecho de que un único usuario sea atendido por la máquina garantiza a las aplicaciones exigentes en recursos el tiempo de respuesta requerido. La carga que introduce en una máquina la ejecución de procesos de otras máquinas no permite que sigamos hablando de ella como una estación personal. En consecuencia, cuando un usuario vuelve, los procesos remotos arrancados en su máquina deben de ser abortados, mejor de una forma suave. Una terminación traumática puede provocar perder el trabajo hecho. Para conseguir una terminación suave, el programa debe ser escrito para soportar esta eventualidad. Una alternativa a la terminación es migrar la ejecución a otra máquina, bien a la local (home workstation) o a otra remota. No hay problemas en mover el espacio de direccionamiento, sino recoger en el núcleo las estructuras de datos que definen el estado del proceso, como su descriptor de proceso, descriptores de ficheros abiertos, temporizadores activados, etc. Aunque no hay problemas teóricos en ello, existen muchas dificultades prácticas. En cualquiera de los dos casos, es preciso dejar la máquina en el mismo estado en el que la dejó su usuario. Esto requiere no sólo matar el proceso remoto sino sus descendientes y todos sus recursos como buzones, semáforos, ficheros temporales tanto en disco como en la caché, etc. También es preciso considerar las llamadas RPC del proceso cuyas réplicas no han vuelto en el momento de eliminar el proceso. El modelo de fondo de procesadores Sacar provecho de las estaciones ociosas añade potencia al sistema, pero no resuelve un problema fundamental que es el de disponer de más CPU’s que usuarios. Con el descenso del precio en los procesadores, puede darse el caso de un sistema en el que el número de procesadores sea 10 o incluso 100 veces mayor que el de usuarios. La pregunta que surge es cómo utilizar estos nuevos recursos. Una solución es construir estaciones de trabajo multiprocesador, pero resulta ineficiente, ya que demasiados recursos están asignados de antemano a un usuario que la mayoría del tiempo no utiliza más que una CPU. La alternativa es construir un fondo de procesadores que pueden ser asignados a los usarios sobre demanda. A mediada que un usuario necesita más potencia de cálculo se le asignan nuevos procesadores y viceversa. La figura 4.12 ilustra la idea. La motivación del fondo procesadores está copiada de la del servidor de ficheros. Al igual que los ficheros se centralizan en un número reducido de máquinas denominadas servidores de ficheros para economizar en número de discos, ventiladores, etc, se puede disponer de nodos que actúan como servidores de potencia de cómputo. Los servidores de cómputo permiten un ahorro de estaciones considerable en un sistema distribuido. Todas las UCP’s se disponen en un panel frontal -rack- requiriendo un único punto de alimentación y de refrigeración. El rack puede ir en una habitación apropiada, fuera del acceso de los usuarios, que únicamente disponen de terminales X o terminales convencionales. Lo que es más importante, el modelo desacopla el número de usuarios del número de UCP’s, que es una característica del modelo de estaciones de trabajo. A los usuarios, el sistema operativo les asigna las UCP que necesiten en cada momento de forma dinámica.
Fig. 4.12 Un sistema basado en el modelo de fondo de procesadores. El modelo de fondo de procesadores se fundamenta en la teoría de colas. Los elementos básicos de esta teoría se basan en un servidor al que llegan aleatoriamente peticiones de trabajo. Cuando el servidor está ocupado, las peticiones esperan en una cola, como ocurre en tantas situaciones de la vida real, sea en supermercados, oficinas de correos o la matriculación de estudiantes, según ilustra la figura 4.13. El interés de la teoría de colas radica en que es posible obtener de ellas información de forma analítica. Sea la tasa de entrada de peticiones por segundo del total de los usuarios y sea las peticiones que el sistema atiende en un segundo. Si , el sistema es estable, por que el sistema es capaz de atender el flujo de peticiones. Ambos valores no son constantes, sino las medias de variables aleatorias. Existirán periodos en que las peticiones superen la capacidad del servicio, formándose una cola de peticiones en espera de servicio. Estos periodos vendrán sucedidos por otros de menor número de peticiones y, por tanto, de disminución de la cola hasta su desaparición. Lo importante es que los valores medios cumplan la desigualdad anterior para garantizar la estabilidad del sistema. Se puede demostrar que el tiempo medio que transcurre desde que se emite una petición hasta que se obtiene una respuesta completa viene dado por la fórmula
Fig. 4.13 Un sistema de colas básico. Supongamos ahora un sistema de n estaciones multiprocesador, cada una de ellas con un número determinado de UCP’s. En cada estación, con una tasa de llegada y una tasa de servicio , el tiempo medio de respuesta es T. Vamos a pasar ahora del modelo de estaciones de trabajo al modelo de fondo de procesadores. Reuniendo los n multiprocesadores en un fondo de procesadores logramos una máquina n veces más potente que cada una de las estaciones individuales, con una capacidad de servicio de peticiones por segundo. Como todas las peticiones de las n estaciones van a parar ahora al fondo de procesadores, esta máquina recibe una tasa de solicitudes de peticiones por segundo. El tiempo medio de respuesta de este nuevo sistema combinado es
que viene a decir que agrupando n pequeños recursos en un recurso n veces más potente, podemos reducir el tiempo de respuesta n veces. Este resultado es teórico y, por lo tanto, puede aplicarse a todo tipo de sistemas. Es más rentable a una empresa de transportes disponer de un autobús que sale cada hora de una estación central que de cuatro minibuses que salen cada hora de cuatro puntos distintos de la ciudad, por ejemplo. La razón es que en el primer modelo, se suceden los intervalos de tiempo en que parte de los multiprocesadores están ociosos mientras la otra parte de los multiprocesadores puede estar sobrecargada. En estos periodos, la potencia de cálculo de los procesadores ociosos no está aprovechado, al mismo tiempo que las peticiones en los multiprocesadores sobrecargados se sirven más lentamente. Desde luego, el argumento anterior es uno de los más fuertes que juega en contra del concepto de sistema distribuido. A una organización se le presentan dos opciones a la hora de realizar su informatización. Supongamos que se calcula que sus procesos exigen un sistema de una potencia de 1000 millones de instrucciones por segundo (MIPS). Se puede optar por un sistema centralizado de 1000 MIPS o de una red de 100 estaciones de 10 MIPS. El sistema de 1000 MIPS será 100 veces más rápido, algo que aboga por concentrar la potencia de cómputo lo más posible, justo lo contrario de lo que dicta la tendencia actual hacia sistemas distribuidos. ¿Por qué entonces esta tendencia? La respuesta es que el tiempo medio de respuesta de un sistema no lo es todo. Uno de los factores a favor de los sistemas distribuidos es el costo. Si el costo de 100 PC’s es muchísimo menor que el de un mainframe de 1000 MIPS, la razón prestaciones/precio juega a favor del sistema distribuido. La tolerancia a fallos es mejor en la red de PC’s, así como el hecho de que no es posible construir un sistema de una potencia arbitraria debido a los límites de la tecnología actual. Es importante también no sólo el tiempo de respuesta sino la varianza en el mismo. Los usuarios no notan tiempos de respuesta muy diferentes siempre que la interacción humana con el sistema sea lo suficientemente rápida en el caso más lento y lo que no toleran es un sistema muy rápido por término medio pero que en ocasiones se vuelve exasperadamente lento. Un tiempo de respuesta uniforme y suficientemente ágil es lo que garantiza el modelo de estaciones de trabajo. Anteriormente hemos dicho que el modelo de fondo de procesadores se fundamenta en la teoría de colas. Considerando que un fondo de n procesadores es n veces más potente que una estación de trabajo, la teoría de colas revela que el tiempo de respuesta del fondo de n procesadores es n veces más rápido que el tiempo de respuesta de cada una de las estaciones en particular. Este argumento, que juega a favor de la solución del fondo de procesadores frente a la solución de las estaciones de trabajo es, desgraciadamente, falaz. No es cierto que un fondo de n procesadores sea n veces más potente que un único procesador. Para sacar partido a n procesadores, es preciso descomponer un problema en n procesos que corran en paralelo, cada uno de ellos asignado a un procesador. Cuando en el sistema existen menos procesos que procesadores, los procesadores ociosos restan potencia al sistema. Aún así, aunque el tiempo de respuesta no sea n veces mejor, el modelo de fondo de procesadores es una mejor solución distribuida que el espiar a otros usuarios para lanzar mandatos remotos en sus máquinas y evita los problemas que surgen a la vuelta de este. Por otra parte, optar por una u otra solución depende de la naturaleza del trabajo que se realiza en el sistema. En un entorno de ofimática, en la que la actividad principal puede ser editar documentos y enviar correo electrónico, el modelo de estación de trabajo sea seguramente suficiente. En grandes proyectos de programación, que donde continuamente se invoca el mandato make o en aplicaciones matemáticas donde el problema sea resolver continuamente sistemas de ecuaciones, el modelo de fondo de procesadores posiblemente sea el más adecuado. También es posible un modelo híbrido donde cada usuario dispone de su estación de trabajo y existe un fondo de procesadores a disposición de las aplicaciones más exigentes en términos de uso de UCP. Este modelo proporciona a la vez un tiempo de respuesta adecuado y un uso eficiente de recursos.
