Para entender mejor el funcionamiento de Condor a la hora de ejecutar un trabajo, se realiza una comparación de lo que ocurre con las llamadas del sistema si una tarea se ejecuta en un único nodo y lo que ocurre cuando un nodo realiza las llamadas al sistema remoto para ejecutar una tarea.
En la figura 14 se muestra el comportamiento interno de un nodo cuando se ejecuta un programa. El código generado por el usuario interactúa con el kernel del sistema operativo por medio de llamadas internas del mismo con el fin de ejecutar dicha tarea. En la figura 4 también se muestra cómo trabaja el mecanismo de llamadas al sistema remoto para ejecutar un programa y cómo interactúan dos nodos específicos de un pool de Condor.
Cuando se inicia la ejecución del código del usuario en un nodo, se involucran algunas llamadas al sistema, por ejemplo para el acceso a ficheros, las cuales son interceptadas por el código Condor enlazado al código del usuario de la tarea que se ejecuta (la cual fue enlazada mediante las librerías de Condor, mediante el comando de Condor
condor_compile). Las librerías de Condor convierten estas llamadas al sistema en
llamadas a procedimiento remoto (Remote System Calls) en el nodo emisor de la tarea para que ésta pueda ser ejecutada. La invocación a esa llamada al sistema se realiza por tanto en el nodo emisor del trabajo, y su resultado se devuelve al nodo de ejecución. Por tanto se trabaja de forma transparente, como si la tarea se ejecuta en el nodo de forma local.
Figura 14. Llamadas al sistema regulares y llamadas remotas al sistema
Es importante destacar que Condor no necesita que los datos estén disponibles en la estación de trabajo remota antes de la ejecución del trabajo, incluso en ausencia de un sistema de archivos compartido.
Condor puede configurarse para ejecutar trabajos en ciertos nodos, sólo cuando el teclado y la CPU estén ociosos. Si el trabajo está ejecutándose en un nodo, regresa el usuario del mismo y presiona una tecla, Condor puede migrar el trabajo a otro puesto y continuar su ejecución desde el punto en el que quedó pendiente.
Este mecanismo también permite planificar en base a prioridades en el pool. Cuando un nodo del pool no está planificado para ejecutar un trabajo, Condor lo utiliza de manera oportunística, pero cuando se necesita ese nodo para ejecutar un determinado trabajo, según lo haya definido el mecanismo de planificación, Condor se apropiará de ese recurso y de cualquier otro que esté ejecutando un trabajo asignado de manera oportunística.
4.4.1 Estado de las máquinas
Es importante conocer el estado en el que se encuentra cada uno de los nodos del pool de Condor así como también las actividades que están realizando en cada momento [37]. Los estados en los que pueden encontrarse los nodos son:
Owner: el estado owner indica que el nodo está en uso en este momento o bien no está
disponible para ejecutar los trabajos que Condor solicite. Este es el estado en el que se encuentran los nodos cuando se encienden y la única actividad posible en este estado es Idle.
Idle: Condor considera que un nodo se encuentra Idle cuando el usuario está utilizando el nodo para ejecutar trabajos que no pertenecen a Condor.
Unclaimed: en este estado el nodo está disponible para ejecutar trabajos de Condor,
pero no lo está haciendo en este momento. Las actividades posibles en este estado son: Idle: los nodos en estado unclimed por defecto se encuentran idle. Un nodo que se encuentra en estado unclaimed permite que se ejecuten trabajos de Condor, aunque en este momento no lo está haciendo.
Benchmarking: el nodo está ejecutando benchmarks para determinar su velocidad. Esta actividad solo sucede en el estado unclaimed.
Matched: este estado indica que el nodo está disponible para ejecutar tareas y la única
actividad en la que puede encontrarse es idle.
Idle: el nodo se encuentra en condiciones para ejecutar tareas pero todavía no lo está haciendo.
Claimed: cuando el nodo se encuentra en este estado es porque ha sido seleccionado
por un demonio Schedd. Pueden darse tres actividades diferentes en el estado claimed: Idle: en esta actividad, el nodo ha sido elegido para ejecutar un trabajo de Condor, pero el demonio Schedd que lo seleccionó todavía tiene que activar la selección por medio de una petición al proceso condor_starter para atender el trabajo.
Busy: una vez que el demonio Schedd se comunica con el proceso
condor_starter para atender el trabajo, el nodo pasa a la actividad busy, indicando que
se encuentra ocupado ejecutando un trabajo.
Suspended: puede suceder que la ejecución del trabajo sea suspendido por Condor, por lo que el nodo cambiará a la actividad suspended. Es importante mencionar que el nodo sigue en estado claimed, pero el trabajo no se está ejecutando momentáneamente, por lo que Condor no devuelve ningún resultado.
Preempting: este estado indica que se ha interrumpido la ejecución de un trabajo de
Condor porque el usuario del nodo ha comenzado a utilizarlo.
Vacating: esta actividad indica que el trabajo que se ejecutó está pasando por el proceso de checkpointing. Ni bien se complete este proceso de chequeo, el nodo cambia hacia el estado owner o el estado claimed.
Killing: este estado indica que el nodo ha solicitado que el trabajo que estaba ejecutando libere inmediatamente el nodo sin hacer el proceso de checkpointing.
4.4.2 Gráfico del estado, actividad y transiciones de las máquinas
En la figura 15 se presentan los estados y actividades en los que puede encontrarse un nodo en un pool de Condor. Las flechas indica el orden en el que un nodo puede pasar de un estado a otro.
Figura 15. Diagrama de estados, actividades y transiciones de un nodo en un pool de Condor
• Al iniciar Condor en un nodo, su estado inicial es owner y su actividad es idle. Luego de que ha pasado un cierto tiempo de inactividad y dependiendo de cómo este configurado Condor, el nodo pasará al estado unclaimed, notificando al administrador central del pool de Condor que está disponible para ejecutar trabajos.
• En el caso de que el nodo sea ocupado por su usuario, el nodo cambiará al estado owner.
• Si el nodo está disponible para ejecutar trabajos de Condor y mientras el demonio Schedd se comunique con el demonio Negotiator que reside en el administrador central del pool de Condor, el nodo cambiará su estado y pasará al estado matched.
• Cuando un nodo se encuentra en el estado matched, pueden ocurrir dos cosas: 1. El nodo puede volver directamente al estado owner porque el usuario del
mismo ha comenzado a utilizarlo, razón por la cual ese nodo ya no podrá ejecutar trabajos de Condor.
2. El nodo va a ejecutar un trabajo de Condor, con lo cual cambia al estado Claimed. A su vez puede encontrarse en:
1. Idle, debido a que el demonio Schedd no ha recibido la petición del proceso condor_starter para ejecutar un trabajo,
2. Busy donde el proceso condor_starter ha sido iniciado o 3. Suspended, donde se ha suspendido el trabajo de Condor.
• Desde el estado claimed, sólo se puede pasar al estado preempting, y este es el estado en el que el trabajo termina. Si el nodo se encuentra en actividad vacating, entonces el trabajo está en proceso de checkpoint o en la actividad killing donde se finaliza el trabajo sin realizar checkpoint.
• En el estado preempting pueden ocurrir dos cosas:
• Que el nodo vuelva al estado claimed, para terminar la ejecución de algún trabajo que no ha concluido.
• Que el nodo pase al estado owner donde finaliza el ciclo de ejecución de un trabajo.
En el caso de que los trabajos que se ejecutan sobre Condor no sufran interrupciones por parte de los usuarios de los nodos o cualquier tipo de fallos, las flechas rojas indican el ciclo de estados que atravesaría una máquina durante la ejecución de ese trabajo.