Subsecciones

3.1 SISTEMAS OPERATIVOS

Introducción

Los ordenadores se están convirtiendo en una plataforma cada vez más abierta y los sistemas operativos tienen que dar los servicios necesarios para que esto pueda gestionarse de manera adecuada, así si hacemos un breve repaso a la historia de los sistemas operativos podemos ver que cada vez tienen más posibilidades de comunicación.

Cuando se construyeron las primeras redes de computadores se vio la potencia que tenían estos sistemas y se desarrolló el paradigma cliente/servidor. Se crearon los sistemas operativos de red con servicios como NFS o FTP para acceder a sistemas de ficheros de otros ordenadores, Xwindow, lpd ... y un conjunto de herramientas que permitían el acceso a recursos compartidos.

En los aurales de la informática el sistema operativo ni siquiera existía, se programaba directamente el hardware, poco a poco se vio que era muy pesado y se hizo una nueva abstracción que evitaba al programa tener que tener un conocimiento total del hardware. Se descubrió también que con un solo proceso se desperdiciaba tiempo de procesador y como tales dispositivos eran carísimos se empezaron a inventar mecanismos que evitasen que el programa esperase a una entrada/salida3.1 hasta que se llegó a la multiprogramación en el ambicioso MULTICS y el exitoso UNIX. Estos dos sistemas se desarrollaron a finales de los años 60 y se basaban en el MIT Compatible Timesharing System realizado sobre 1958. En los años 70 se añadieron las primeras capacidades de interconexión:

Este sistema operativo fue ampliamente usado porque integraba las capacidades de comunicación, implementaba TCP/IP y tenía capacidades de comunicación entre procesos.



Un sistema operativo distribuido puede acceder a cualquier recurso transparentemente y tiene grandes ventajas sobre un sistema operativo de red pero es muy difícil de implementar y algunos de sus aspectos necesitan que se modifique seriamente el núcleo del sistema operativo (por ejemplo para conseguir memoria distribuida transparente a los procesos). También se tiene que tener en cuenta que ahora la máquina sobre la que corre todo el sistema es el sistema distribuido (un conjunto de nodos) por lo que tareas como planificación de procesos (scheduling) o los hilos ( threads) y señales entre procesos toman una nueva dimensión de complejidad. Por todo esto aún no existe ningún sistema distribuido con todas las características de transparencia necesarias.

A partir de ahora no hablaremos de computadores, ordenadores ni PC. Cualquier dispositivo que se pueda conectar a nuestro sistema y donde se pueda desarrollar un trabajo útil para el sistema se referenciará como nodo. El sistema operativo tiene que controlar todos estos nodos y permitir que se comuniquen eficientemente.

Aunque tras leer este capítulo el lector podrá intuir esta idea, queremos hacer notar que un sistema distribuido se puede ver como el siguiente nivel de abstracción sobre los sistemas operativos actuales. Como hemos visto la tendencia es a dar más servicios de red y más concurrencia. Si pusiéramos otra capa por encima que aunara ambos, esta capa sería el sistema operativo distribuido. Esta capa debe cumplir los criterios de transparencia que veremos en el próximo apartado. Podemos comprender esto mejor haciendo una analogía con el SMP, cuando sólo existe un procesador todos los procesos se ejecutan en él, tienen acceso a los recursos para los que tengan permisos se usa la memoria a la que puede acceder el procesador, etc. Cuando tenemos varios procesadores todos ellos están corriendo procesos (si hay suficientes para todos) y los procesos migran entre procesadores.

En un sistema multiprocesador al igual que un sistema multicomputador hay una penalización si el proceso tiene que correr en un elemento de proceso (procesador o nodo) distinto al anterior (en multiprocesador por la contaminación de cache y TLB y en multicomputador por la latencia de la migración y pérdidas de cache). En un sistema multicomputador se persigue la misma transparencia que un sistema operativo con soporte multiprocesador, esto es que no se deje ver a las aplicaciones que realmente están funcionando en varios procesadores. Asímismo todas las demás transparencias implícitas en un sistema multiprocesador deben conseguirse en un sistema multicomputador.

En este capítulo además vamos a tratar qué zonas de un sistema operativo se ven más afectadas para conseguir todo esto, hablaremos de los métodos que hemos recogido en la bibliografía, opinaremos sobre ellos y explicaremos el caso práctico de como han solucionado el problema Linux y openMosix. Estas zonas afectadas son:

3.1.1 Procesos y Schedulling

3.1.1.1 Migración de procesos: ¿por qué es útil?

Migración de procesos es mover el proceso desde donde originarialmente se está ejecutando a un nuevo entorno. Aunque no se suela emplear en este caso, se podría hablar de migración cuando un proceso se mueve de procesador. Aquí consideraremos migración cuando un proceso se mueve de un nodo a otro.

En un sistema de tipo cluster lo que se pretende, como se verá en el capítulo de clusters, es compartir aquellas tareas para las que el sistema está diseñado, i.e. sus funcionalidades. Uno de los recursos que más se desearía compartir, aparte del almacenamiento de datos, que es algo ya muy estudiado y por lo menos existen varias implementaciones, es el procesador de cada nodo. Para compartir el procesador entre varios nodos, lo más lógico es permitir que las unidades atómicas de ejecución del sistema operativo sean capaces de ocupar en cualquier momento cualesquiera de los nodos que conforman el cluster. A ese paso de un nodo a otro de un proceso se le llama migración del proceso.



En un sistema multiprogramable y multiusuario de tiempo compartido, la elección de qué proceso se ejecuta en un intervalo de tiempo determinado, la hace un segmento de código que recibe el nombre de scheduler u planificador. Una vez que el scheduler se encarga de localizar un proceso con las características adecuadas para comenzar su ejecución, es otra sección de código llamada dispatcher la que se encarga de substituir el contexto de ejecución en el que se encuentre el procesador, por el contexto del proceso que queremos correr. Las cosas se pueden complicar cuando tratamos de ver este esquema en un multicomputador. En un cluster, se pueden tener varios esquemas de actuación.

Otra de las políticas que puede variar del scheduling en un ordenador individual a un cluster, es la de diseminación de la información de los nodos. A la hora de elegir sobre qué nodo migrar un proceso, tanto en el scheduling conjunto como en el individual, se debe conocer la información de los nodos para balancear convenientemente el sistema. Esta diseminación puede estar basada en: De estos dos, el primero no es muy escalable, pero probablemente sea más adecuado en ciertas condiciones. No hemos encontrado ningún sistema que intente un sistema de scheduling en conjunto o general para todo el cluster, sino que se deja las decisiones sobre cuándo ejecutar cada proceso a cada nodo particular por tanto la principal novedad en un sistema distribuido es que tenemos que permitir que los procesos se ejecuten en cualquier computador no necesariamente en el que se crearon. Este ha sido un tema estudiado numerosas veces, con todo tipo de conclusiones, la más sorprendente es la de Tanenbaum3.2:

La migración real de procesos en ejecución es trivial en teoría, pero cerca de lo imposible en la práctica.

Tanenbaum se equivoca (una vez más) porque openMosix ha conseguido la migración en la práctica. La migración de procesos tiene varias ventajas, como son:

Las principales decisiones que se deben tomar en un sistema distribuido para hacer esta migración eficiente las podemos englobar en tres políticas distintas: A parte de estas políticas también tenemos que hacer otras consideraciones que no tienen que ver con las decisiones que tomamos sino como van a ser implementadas en la práctica, estas son:

3.1.1.2 Política de localización

¿Desde dónde se lanzaran los procesos o dónde comenzaran los procesos?

Este tipo de planteamiento sólo se efectúa en los sistemas SSI de los que hablaremos más tarde, ya que necesita un acoplamiento muy fuerte entre los nodos del cluster. Un ejemplo, puede ser el requerimiento de un cluster que dependiendo del usuario o grupo de usuario, elija un nodo preferente donde ejecutarse por defecto. Por ejemplo, en openMosix, no se hace uso de esta política, ya que el sistema no está tan acoplado como para hacer que otro nodo arranque un programa.

3.1.1.3 Política de migración

La política de migración plantea las decisiones que hay que hacer para responder a preguntas, a saber: Para saber cuándo se debe realizar una migración nuestro nodo debe estar en contacto con los demás nodos y recolectar información sobre su estado y así, y teniendo en cuenta otros parámetros como la carga de la red, se debe hacer una decisión lo más inteligente posible y decidir si es momento de migrar y qué es lo que se migra.

Las causas que hacen que se quiera realizar la migración van a depender del objetivo del servicio de la migración. Así si el objetivo es maximizar el tiempo usado de procesador, lo que hará que un proceso migre es el requerimiento de procesador en su nodo local, así gracias a la información que ha recogido de los demás nodos decidirá si los merece la pena migrar o en cambio los demás nodos están sobrecargados también.

La migración podría estar controlada por un organismo central que tuviera toda la información de todos los nodos actualizada y se dedicase a decidir como colocar los procesos de los distintos nodos para mejorar el rendimiento, esta solución aparte de ser poco escalable pues se sobrecargan mucho la red de las comunicaciones y estamos sobrecargando uno de los equipos, su mayor error es que si este sistema falla se dejarán de migrar los procesos.

El otro mecanismo es una toma de decisiones distribuida, cada nodo tomará sus propias decisiones usando su política de migración asignada. Dentro de esta aproximación hay dos entidades que pueden decidir cuando emigrar: el proceso o el kernel. Si el proceso es quien va a decidirlo tenemos el problema de que el proceso tiene que ser consciente de la existencia de un sistema distribuido. En cambio si es el kernel quién decide tenemos la ventaja de que la función de migración y la existencia de un sistema distribuido puede ser transparente al proceso. Esta es la política que usa openMosix.

3.1.1.4 Política de ubicación

Encontrar el mejor nodo donde mandar un proceso que está sobrecargando el nodo nativo no es una estrategia fácil de implementar.

Entran en juego una gran amplia gama de algoritmos generalmente basados en las funcionalidades o recursos a compartir del cluster, y dependiendo de cuáles sean estos, se implantaran unas medidas u otras en él. El problema no es nuevo y puede ser tratado como un problema de optimización normal y corriente, pero con una severa limitación. A pesar de ser un problema de optimización se debe tener en cuenta que este código va a ser código de kernel, por lo tanto y suponiendo que está bien programado, el tiempo de ejecución del algoritmo es crucial para el rendimiento global del sistema. ¿De qué sirve optimizar un problema de ubicación de un proceso que va a tardar tres segundos en ejecutarse, si dedicamos uno a decidir donde colocarlo de manera óptima y además sin dejar interactuar al usuario?

Este problema penaliza a ciertos algoritmos de optimización de nueva generación como las redes neuronales, o los algoritmos genéticos y beneficia a estimaciones estadísticas.

3.1.1.5 Parte de los procesos a migrar

Una vez que sabemos cuándo y de dónde, hacia dónde migramos, nos falta saber qué parte del proceso se va a migrar. Hemos encontrado dos aproximaciones:
  1. migrar todo el proceso
  2. migrar una parte del proceso
Veamos con más detenimiento estas dos opciones:
  1. Migrar todo el proceso.

    Implica destruirlo en el sistema de origen y crearlo en el sistema de destino. Se debe mover la imagen del proceso que consta de, por lo menos, el bloque de control del proceso (a nivel del kernel del sistema operativo). Además, debe actualizarse cualquier enlace entre éste y otros procesos, como los de paso de mensajes y señales (responsabilidad del sistema operativo). La transferencia del proceso de una máquina a otra es invisible al proceso que emigra y a sus asociados en la comunicación.

    El movimiento del bloque de control del proceso es sencillo. Desde el punto de vista del rendimiento, la dificultad estriba en el espacio de direcciones del proceso y en los recursos que tenga asignados. Considérese primero el espacio de direcciones y supóngase que se está utilizand o un esquema de memoria virtual (segmentación y/o paginación). Pueden sugerirse dos estrategias:

  2. Migrar una parte del proceso.

    En este sistema el contexto del nivel de usuario que es llamado remote, contiene el código del programa, la pila, los datos, el mapeo de la memoria y los registros del proceso. El remote encapsula el proceso cuando este está corriendo en el nivel de usuario. El contexto del kernel es llamado deputy, este contiene la descripción de los recursos a los cuales el proceso está unido, y la pila del kernel para la ejecución del código del sistema cuando lo pida el proceso.

    Mantiene la parte del contexto del sistema que depende del lugar por lo que se mantiene en el nodo donde se generó el proceso. Como en Linux la interface entre el contexto del usuario y el contexto del kernel está bien definida, es posible interceptar cada interacción entre estos contextos y enviar esta interacción a través de la red. Esto está implementado en el nivel de enlace con un canal especial de comunicación para la interacción. El tiempo de migración tiene una componente fija que es crear el nuevo proceso en el nodo al que se haya decidido migrar y una componente lineal, proporcional al número de páginas de memoria que vayamos a transferir. Para minimizar la sobrecarga de esta migración de todas las páginas que tiene mapeadas el proceso sólo vamos a enviar las tablas de páginas y las páginas en las que se haya escrito algo.

    openMosix consigue transparencia de localización gracias a que las llamadas al sistema que realiza el proceso que ha migrado que sean dependientes del lugar donde se encuentra el proceso se envían a través de la red al deputy. Así openMosix intercepta todas las llamadas al sistema, comprueba si son independientes o no, si lo son las ejecuta de forma local (en el lugar remoto) sino la llamada se emitirá al nodo de origen y la ejecutará el deputy, este devolverá el resultado de vuelta al lugar remoto donde se continua ejecutando el código de usuario.

3.1.1.6 Mecanismos de migración

Métodos para comunicar el estado de cada procesador, nodo, dependiendo de política centralizada o distribuida.

Se tratarán de manera general los problemas a los que nos enfrentamos en estos sistemas, en el siguiente apartado veremos una implementación particular.

Los mecanismos de migración van a depender de algunas de las decisiones anteriores y son su implementación práctica. Normalmente las políticas de ubicación y localización no suelen influir en estos mecanismo pues en general, una vez que el proceso migra no importa donde migre. Así por ejemplo si hemos decidido que los mismos procesos son quienes lo deciden todo (automigración) llegamos a un mecanismo de migración que es el usado en el sistema operativo AIX de IBM.

  1. Cuando un proceso decide migrar, selecciona la máquina destino y envía un mensaje de tarea remota. El mensaje lleva una parte de la imagen del proceso y de información de archivos abiertos.

  2. En el nodo receptor, un proceso servidor crea un hijo y le cede esta información.

  3. El nuevo proceso extrae los datos, los argumentos, la información del entorno y de la pila que necesita hasta completar su operación.

  4. Se indica con una señal al proceso originario que la migración ha terminado. Este proceso envía un mensaje final para terminar la operación al nuevo proceso y se destruye.
Si en cambio es otro proceso el que comienza la migración en vez de ser el propio proceso tenemos el sistema que se usa en Sprite, se siguen los mismos pasos que en AIX pero ahora el proceso que maneja la operación lo primero que hace es suspender el proceso que va a migrar para hacerlo en un estado de no ejecución. Si el proceso que decido no está en cada máquina sino que hay solamente uno que hace decisiones globales, tenemos una toma de decisiones centralizada. En este caso se suele usar unas instrucciones especiales desde esa máquina a las máquinas origen y destino de la migración, aunque básicamente se sigue el patrón expuesto del sistema AIX.

También puede ocurrir que se necesite un consenso de un proceso en la máquina origen y otro proceso en la máquina destino, este enfoque tiene la ventaja de que realmente se asegura que la máquina destino va a tener recursos suficientes, esto se consigue así:

  1. El proceso controlador de la máquina origen (después de las decisiones oportunas) le indica al proceso controlador de la máquina destino que le va a enviar un proceso, este proceso le responde afirmativamente si está preparado para recibir un proceso.

  2. Ahora el proceso controlador de la máquina origen puede hacer dos cosas: ceder el control al núcleo para que haga la migración o pedir al núcleo estadísticas del proceso y se las envía al proceso controlador destino (el núcleo hace lo mismo si toma el control).

  3. El proceso controlador de la máquina destino o su núcleo toman esa información (el proceso se la envía al núcleo) y deciden si hay suficientes recursos en el sistema para el nuevo proceso, si lo hubiera el núcleo reserva los recursos necesarios para el proceso y lo notifica al proceso controlador que notifica al proceso controlador de la máquina origen que proceda con la migración.

3.1.2 Compartición de recursos

Problemas

Para entender como compartir recursos en un sistema distribuido se plantean nuevos problemas respecto a compartirlos en un sólo sistema, vamos a poner un ejemplo, cuando dos procesos (supongamos dos ejemplares del mismo proceso) que comparten memoria y que acceden a una misma variable inicializada con el valor 5, a la que llamaremos contador, en una determinada parte del programa se incrementa este contador, esto es lo que nosotros esperamos que ocurra:

Tabla: Sistemas Operativos. Compartición de recursos (1)
Instancia 1 Instancia 2
lee(contador)  
a nade(contador,1)  
escribe(contador)  
  lee(contador)
  a nade(contador,1)
  escribe(contador)


Si esto ocurriera así, la primera instancia del programa pondrá el contador a 6, entonces la segunda instancia del programa, lee ese valor 6 y escribe el valor 7. Pero si no usamos unos mecanismos necesarios esto es lo que ocurrirá:

Tabla: Sistemas Operativos. Compartición de recursos (2)
Instancia 1 Instancia 2
lee(contador)  
a nade(contador,1) lee(contador)
escribe(contador) a nade(contador,1)
  escribe(contador)
   
   


Esto se suele traducir en que el programa parece fallar de forma aleatoria y en un fallo difícil de encontrar.

Esto es lo que se llama una condición de carrera y desde que linux funciona en máquinas SMP (a partir de la versión 2.0 ) se ha convertido en un tema principal en su diseño como implementación, por supuesto no es un problema único de Linux sino que atañe a cualquier sistema operativo. La solución pasa por encontrar estos puntos y protegerlos con locks, bloqueos o interbloqueos, para que sólo uno de los procesos pueda entrar a la vez a la región crítica. Vamos a ver como ejemplo práctico que instrumentos se usan en el kernel de Linux para evitar estas situaciones y que consecuencias tiene el poder compartir recursos remotos.

3.1.3 El problema de la memoria

3.1.4 Comunicación entre procesos

En un cluster existe un nuevo problema, si movemos un proceso y lo movemos a otro nodo, ese proceso debe seguir pudiendo comunicarse con los demás procesos sin problemas, por lo que necesitamos enviar las señales que antes eran locales al nodo a través de la red.

Por tanto cada sistema tiene sus propias primitivas de comunicación para enviar toda la comunicación a través de la red. Hay mecanismos de comunicación más problemáticos que otros, por ejemplo las señales no son demasiado problemáticas pues se puede encapsular en un paquete qué se envíe a través de la red y el sistema destino coge el paquete, saca la información de que proceso emitió la señal, que señal fue y a qué proceso se emite y ya se tiene una forma global de enviar señales. El único problema es que implicaría que el sistema debe saber en todo momento el nodo dónde está el proceso con el que quiere comunicar o hacer una comunicación broadcast a todos los nodos para enviar una sola señal. Otros mecanismos de comunicación entre procesos son más complejos de implementar, por ejemplo la memoria compartida, se necesita tener memoria distribuida y poder compartir esa memoria distribuida. Los sockets como el caso de la familia Unix, o inet, también son candidatos difíciles a migrar por la relación que tienen los servidores con el nodo. Para migrar estas interacciones entre procesos de manera elegante y eficiente se necesita un sistema especialmente diseñado para ello, por ejemplo del tipo SSI de Compaq.

3.1.5 La importancia de los sistemas de ficheros

Los sistemas de ficheros son necesarios en nuestros sistemas tradicionales para mantener de forma permanente la información y compartir información entre usuarios y programas. Un fichero no es más que una abstracción del dispositivo de almacenaje permanente.

El sistema de ficheros tradicional tiene como funciones la organización, almacenaje, recuperación, protección, nombrado y compartición de ficheros. Para conseguir nombrar los ficheros se usan los directorios, que no son más que un fichero de un tipo especial que provee una relación entre los nombre que ven los usuarios y un formato interno del sistema de ficheros.

Un sistema de ficheros distribuido es tan importante para un sistema distribuido como para uno tradicional, debe mantener las funciones del sistema de ficheros tradicional, por lo tanto los programas deben ser capaces de acceder a ficheros remotos sin copiarlos a sus discos duros locales y proveer acceso a ficheros en los nodos que no tengan disco duro. Normalmente el sistema de ficheros distribuido es una de las primeras funcionalidades que se intentan implementar y es de las más utilizadas por lo que su buena funcionalidad y rendimiento son críticas. Se pueden diseñar los sistemas de ficheros para que cumplan los criterios de transparencia, cumplir los criterios quiere decir que tenemos los siguientes características deseables:

Para comprender mejor el problema vamos a ver cuatro sistemas de ficheros que desde el más simple a otros más complejos han intentado solucionar estos problemas hasta cierto grado. Estos sistemas de ficheros son: A continucación se enumeran sus propiedades básicas y se hará una pequeña comparación entre ellos. La elección de estos sistemas de ficheros entre los muchos que existen no es casual, NFS es bien conocido y aunque existen otros sistemas similares y más avanzados (como AFS, Coda o Intermezzo que como NFS dependen de un servidor central) sus características avanzadas (cache en los clientes de AFS y la adaptación al ancho de banda, reintegración de una comunicación perdida y múltiples peticiones RPC de Coda, simpleza y distinción kernel/programa de usuario de Intermezzo) hacen que sea más complejo comprender las características que se quiere destacar en esta comparativa.
Figura: Sistemas operativos. GFS con servidor central
Image GFS
El modo que no necesita servidor central es llamado modo simétrico, los discos contienen datos y metadatos, que son controlados por cada máquina al ser accedidos, estos accesos son sincronizados gracias a locks globales, que se apoyan en la ayuda del hardware tanto por parte de SCSI (DMEP) como por parte del switch (DLM). Esto hace esta alternativa aún más cara. En la figura 3.3 se muestra un gráfico con una configuración típica de este sistema. Se puede ver que la Network Storage Pool no tiene procesadores, pues está directamente conectada a la red, gracias a fibra óptica y SCSI. La Storage Area Network típicamente es un switch de alta velocidad).
Figura: Sistemas operativos. SAN
Image san
Entre las características que este sistema de ficheros se encuentra que no hay un solo punto de fallo, si un cliente falla, o si incluso muchos clientes quedasen inutilizables, el sistema de ficheros estaría todavía ahíaccesible a todos los clientes que aún estuvieran funcionando. Gracias a que los discos están compartidos por todos los clientes todos los datos a los que los clientes que dieron error estaban accediendo están todavía a disposición de los clientes que estén funcionando.

Aunque de todos estos puntos solo el último sea negativo es una razón bastante fuerte y relega al uso de este sistema para empresas con gran presupuesto que no quieran usar un servidor centralizado.

Este sistema de ficheros cumple todas las transparencias explicadas al principio de la lección, en el caso de haber un servidor central este es el que no cumple los criterios de transparencia pero en la parte de los clientes si los cumple pues no saben dónde están los ficheros (transparencia de acceso), se podrían cambiar de disco duro sin problema (transparencia de localización), si un nodo falla el sistema se recupera (transparencia a fallos), varios clientes pueden acceder al mismo fichero (transparencia de concurrencia) y se mantienen caches en los clientes (transparencia de réplica).

3.1.6 Entrada salida

En un sistema tradicional, la entrada/salida es local al nodo en el que se produce, pero desde la aparición de las redes se han venido aprovechando éstas para acceder a determinados recursos de entrada/salida colocados en un ordenador distante. Por ejemplo es típico en las empresas comprar una única impresora cara para obtener la mejor calidad posible y dejar que esa impresora sea accedida desde cualquier ordenador de la intranet de la empresa, aunque esto significa el desplazamiento físico de los empleados, puede ser un ahorro considerable a instalar una impresora en cada uno de los ordenadores. Otro ejemplo muy común es NFS que permite centralizar los accesos al sistema de ficheros, podemos disponer de ordenadores sin discos duros o permitimos que todo el trabajo se actualice en un solo lugar.

El problema es que para estos dos ejemplos se han desarrollado soluciones específicas que necesitan un demonio escuchando peticiones en un determinado puerto y en el caso de NFS algún cambio en los sistemas de ficheros. Pero desarrollar una solución general es mucho más complejo y quizás incluso no deseable. Para que cualquier nodo pueda acceder a cualquier recurso de entrada/salida, primero se necesita una sincronización que como ya vimos en una sección anterior de este capítulo puede llegar a ser complejo. Pero también se necesitan otras cosas como conocer los recursos de entrada/sali da de los que se dispone, una forma de nombrarlos de forma única a través del cluster etc.

Para el caso concreto de migración de procesos el acceso a entrada y salida puede evitar que un proceso en concreto migre o más convenientemente los procesos deberían migrar al nodo donde estén realizando toda su entrada/salida para evitar que todos los datos a los que están accediendo tengan que viajar por la red. Así por ejemplo un proceso en openMosix que esté muy vinculado al hardware de entrada/salida no migrará nunca (X, lpd, etc.). Los sockets como caso especial de entrada y salida también plantean muchos problemas porque hay servicios que están escuchando un determinado puerto en un determinado ordenador para los que migrar sería catastrófico pues no se encontrarían los servicios disponibles para los ordenadores que accediera n a ese nodo en busca del servicio. Hay gente que apoya el SSI en la que todos los nodos ven el mismo sistema y que no importa donde estén los recursos o los programas porque se acceden a ellos siempre correctamente, esto significaría que los sockets podrían migrar porque realmente no importa donde esté el servicio para acceder a él. Nosotros pensamos que esta aproximación aunque teóricamente muy correcta puede dar varios problemas en la práctica.


miKeL a.k.a.mc2 2003-09-28