Como ya se ha explicado, los nodos en Condor cumplen distintas funciones, y uno de los más importantes es el nodo administrador central. Un grupo de nodos que comparten el mismo administrador central constituye un pool. Los pools pueden unirse mediante el mecanismo de flocking, como se explicó en la subsección 2.4.1. En este caso, el administrador central actúa como un broker de recursos para todo el pool, controlando la ejecución de los trabajos, la disponibilidad de recursos, los nodos que están ejecutando trabajos, etc.
Esto significa que todos los nodos del pool deben poder comunicarse con el administrador central y vice-versa. Sin embargo, hay algunas excepciones:
• Pueden haber nodos que sólo emitan trabajos pero nunca los ejecuten. Estos nodos no necesitan comunicarse entre ellos, pero sí con el administrador central y con los nodos que ejecutan trabajos, por lo tanto la comunicación es
bidireccional.
• Pueden haber nodos que sólo ejecuten trabajos pero que nunca los emitan, entonces estos nodos no necesitan comunicarse entre sí pero deben poder comunicarse con el administrador central y con los nodos que emiten trabajos. En este caso la comunicación también es bidireccional.
En la figura 9 se observa la arquitectura de pool:
Figura 9. Arquitectura de un pool de Condor
En el caso de que los pools estén vinculados mediante el mecanismo de flocking, el escenario sería el siguiente:
• Los nodos que deban enviar un trabajo fuera de su propio pool necesitan comunicarse con el administrador central del pool en el cual ejecutará el trabajo. • Cualquier nodo que emita un trabajo necesita comunicarse con el nodo que
ejecutará ese trabajo, por lo que la comunicación es bidirieccional. Esto quiere decir, en definitiva, que todas las máquinas de cada pool deben poder comunicarse con todas las máquinas de los demás pools.
• Los nodos que sólo emiten trabajos necesitan comunicarse con el administrador central del pool donde se ejecutarán los trabajos y con los nodos que ejecutarán esos trabajos.
cualquier máquina que le envíe trabajos para ejecutar, sin importar el pool al que pertenezcan.
• El caso más general es cuando cada nodo necesita comunicarse con cualquier otro nodo, ya sea que estén en el mismo pool o mediante el mecanismo de flocking.
Es importante destacar que la mayoría de las comunicaciones en Condor se producen sobre UDP más que con TCP, sobre todo a la hora de atravesar un firewall, ya que las reglas suelen ser distintas para un protocolo u otro.
Condor utiliza el puerto 9618 para el demonio condor_collector en el administrador central, pero puede seleccionarse otro número de puerto en el archivo de configuración global.
Para que Condor pueda atravesar un firewall, es necesario que estén abiertos algunos puertos para todos los nodos que sean parte del pool:
• El puerto 9618 para tráfico bidireccional, tanto para TCP como para UDP.
• Un rango de puertos lo suficientemente amplio y por encima del puerto 1024, para tráfico UDP y TCP. La configuración por defecto de Condor ofrece el rango de puertos desde el 9600 al 9700.
Hay tres mecanismos para utilizar firewalls con Condor:
• Restringir a Condor para que utilice un rango determinado de puertos y permitir que las conexiones a través del firewall utilicen cualquier puerto dentro de ese rango.
• Utilizar los mecanismos Condor Connection Brokering (CCB) o Generic Connection Brokering (GCB).
• Configurar una Red Privada Virtual (VPN) para atravesar el firewall. Esta alternativa se ha implementado como un aporte de esta tesis y se desarrolla en la sección 3.16
En el caso de que un pool de Condor esté totalmente detrás de un firewall, no es necesario definir un rango de puertos. Sin embargo, en el caso que el firewall se encuentre dentro de un pool de Condor, entonces habrá que configurar algunas variables para forzar el uso de determinados puertos y rango de puertos.
Por defecto, Condor utiliza el puerto 9618 para que el demonio condor_collector y puertos elegidos aleatoriamente para los demás demonios.
Para definir el rango de puertos que utilizará Condor, deben configurarse las variables HIGHPORT y LOWPORT.
Condor Connection Brokering (CCB) [28] permite la comunicación entre componentes donde uno de ellos se encuentra dentro de una red privada o detrás de un firewall. Por ejemplo, un proceso A de Condor necesita comunicarse con otro proceso B, pero la red no permite que se creen conexiones TCP desde A hacia B sino desde B hacia A. En este caso se puede configurar a B para que se registre en un servidor CCB al cual pueden
conectarse A y B. Entonces, cuando A necesita conectarse con B, le envía una solicitud al servidor CCB, el cual a su vez le indicará a B que se conecte con A.
Condor Connection Brokering no soporta la ejecución de trabajos del universo estándar. Actualmente se está reemplazando GCB [29] con CCB. Básicamente, GCB permite la comunicación entre nodos que están dentro de redes privadas. Se prefiere CCB a GCB porque soporta todas las plataformas, incluyendo Windows, es más sencillo de configurar y para resolver problemas y puede reiniciarse y reconfigurar sobre la marcha, mientras está en uso.
GCB posee varias ventajas pero su configuración es muy complicada. Otras desventajas importantes son:
• El recurso que actúe como GCB representa un punto central de falla.
• Todos los nodos que se encuentran detrás del firewall comparten una única dirección IP, que es la IP pública de su broker GCB. Esto es importante desde el punto de vista de la seguridad y representa cierta complejidad a la hora de realizar un debug del sistema.
• GCB no puede implementar el mecanismo de seguridad Kerberos. • Es complicado establecer las conexiones.
• Cada puerto de cada nodo que se encuentra dentro de la red privada debe corresponder a un único puerto en el nodo que actúe como broker, por lo que hay un número limitado de nodos privados a los que el broker puede darle servicio.
• Cada nodo debe mantener una conexión TCP con su broker. En caso de que el socket se cierre, el broker intentará mantenerlo abierto lo que significa que deberá tener tantos sockets abiertos como nodos privados a los que les da servicio.