Cóndor Programar y ejecutar aplicaciones intensivas de CPU remotas utilizando los ciclos inactivos de estaciones de trabajo de propiedad distribuida
Descargar ahora

Cóndor Clasificación y resumen

Cóndor Etiquetas

calendario remoto correr monitor de recursos ejecución remota solicitud de horario

Cóndor Descripción

Programar y ejecutar aplicaciones intensivas de CPU remotas utilizando los ciclos inactivos de estaciones de trabajo de propiedad distribuida Condor es un sistema especializado de gestión de la carga de trabajo para trabajos de computa intensiva. Al igual que otros sistemas de lotes con todas las funciones, Condor proporciona un mecanismo de cola de trabajo, política de programación, esquema de prioridad, monitoreo de recursos y gestión de recursos. Los usuarios envían sus trabajos seriales o paralelos a Condor, el cóndor los coloca en una cola, elige cuándo y dónde ejecutar los trabajos en función de una política, supervisa cuidadosamente su progreso y, en última instancia, informa al usuario al finalizar. Mientras que proporciona funcionalidad similar a la de Un sistema de colas de lotes más tradicional, la novela de la arquitectura del cóndor le permite tener éxito en las áreas donde los sistemas de programación tradicionales fallan. Condor se puede utilizar para administrar un grupo de nodos de cómputo dedicados (como un clúster "Beowulf"). Además, los mecanismos únicos permiten que el cóndor aproveche de manera efectiva el poder de CPU desperdiciado de las estaciones de trabajo de escritorio de forma inactiva. Por ejemplo, Condor se puede configurar solo para usar las máquinas de escritorio donde el teclado y el mouse estén inactivos. Si el Condor detecta que una máquina ya no está disponible (como una pulsación de teclas detectada), en muchas circunstancias, Condor puede producir transparentemente un punto de control y migrar un trabajo a una máquina diferente, que de otra manera estaría inactiva. Condor no requiere un sistema de archivos compartidos a través de máquinas: si no hay disponible el sistema de archivos compartidos, Condor puede transferir los archivos de datos del trabajo en nombre del usuario, o el Condor puede ser capaz de redirigir de forma transparente todas las solicitudes de E / S del trabajo a la enviar la máquina. Como resultado, Condor se puede usar para combinar sin problemas toda la potencia computacional de una organización en un recurso. Condor monitorea un grupo de máquinas para encontrar máquinas inactivas que luego se usan para completar los trabajos enviados, y también proporciona mecanismos remotos del sistema y puntos de control que permiten la ejecución remota transparente y la migración de trabajos. Nota: Condor tiene licencia y distribuida en la licencia de Apache. ¿Qué hay de nuevo en este lanzamiento: · Esta versión es incompatible al comunicarse con versiones anteriores de Condor si CCB está habilitado o si se configura Private_NetWork_Name. · Actualizado la versión DRMAA. Esta nueva versión cumple con GFD.133, la norma de recomendación de Grid DRMAA 1.0. Se agregaron tres nuevas funciones para cumplir con los requisitos de la especificación, y se solucionaron varios errores. Nuevas características: · Soporte agregado para usar cualquier script reconocido como ejecutable en un archivo de envío en Windows. Para obtener más información, consulte la Sección 6.2.6 en la página . · Soporte mejorado para redes privadas: CCB agregado, el agente de conexión del cóndor. Es similar en funcionalidad para GCB, el agente de conexión genérico, pero tiene varias ventajas, incluida la facilidad de uso y el trabajo en las plataformas de Windows, así como las plataformas UNIX. GCB continúa trabajando, pero podemos eliminarlo algún tiempo en la serie de desarrollo de 7.3. La función principal faltante en CCB en este momento que le impide reemplazar GCB, es compatible con la conectividad de una red privada a otra. CCB solo funciona cuando se conecta de una red pública a una privada. Por ejemplo, los trabajos pueden enviarse desde un Condor_SCHEDD en el Internet Public Internet a Condor_Startd Daemons en una red privada, si los Daemons de Condor_startd están configurados para usar un servidor CCB que se puede acceder al demonio de Condor_Schedd. Sin embargo, si el Daemon de Condor_Schedd está en una red privada y los Daemons de Condor_Startd están en una red privada diferente, CCB no ayuda. Para obtener más información sobre CCB, consulte la Sección 3.7.3. · Soporte adicional para una afinidad de la CPU en las plataformas Linux. · Soporte adicional para la opción Condor_Q -Better-Analize en Windows. · Agregado Want_Hold. Cuando se hace previamente se convierte en cierto, si Want_Hold es cierto, el trabajo se pone en espera por la razón (opcionalmente) especificada por Want_Hold_Reason y Want_Hold_SubCode. Estas expresiones políticas son evaluadas por la máquina ejecutar. Como de costumbre, el propietario del trabajo puede especificar las expresiones periodic_release y / o periodic_remove para reaccionar a los estados de espera específicos automáticamente. · Se ha añadido la función de depuración ClassAd (). Véase la sección 4.1.1 para los detalles de esta función. · El condor_schedd ahora puede utilizar sumas de verificación MD5 para evitar el almacenamiento de varias copias del mismo ejecutable en su directorio de cola. Tenga en cuenta que esta función sólo afecta a los ejecutables enviados a la condor_schedd a través del comando copy_to_spool dentro de un archivo de presentar la descripción. · Reducción de la cantidad de sueños Condor_Dagman hace mantener la consistencia del archivo de registro cuando un DAG utiliza múltiples registros de usuarios para trabajos de nodo. Dagman ahora hace un sueño por ciclo de envío, en lugar de un sueño para cada envío. · Se agregó el indicador de línea de comandos -import_env a Condor_SUBMIT_DAG. Esto pone explícitamente el entorno del submittor en el archivo .condor.sub. · Optimizado la eliminación de un gran número de trabajos. Anteriormente, la eliminación de decenas de miles de empleos hizo que el demonio de Condor_Schedd consumiera una gran cantidad de tiempo de CPU durante varios minutos. · Uso reducido de la memoria por el demonio de Condor_Shadow. Dado que hay un proceso de Condor_Shadow por trabajo en ejecución, esto ayuda a aumentar la cantidad de trabajos en ejecución que puede manejar una máquina de envío. Bajo Linux 2.6, encontramos que ejecutar 10,000 empleos de una máquina de envío solo requiere aproximadamente 10 gbytes de RAM del sistema. También encontramos en este caso que para ejecutar más de 10,000 empleos simultáneos requiere una máquina de envío de 64 bits. En una plataforma Linux de 32 bits, la memoria del kernel está agotada, independientemente de la cantidad de RAM adicional que tenga el sistema. · Reducción del uso de memoria del demonio de Condor_Collector, cuando Update_collector_with_tcp = true. Adiciones de la variable de configuración y cambios: · La nueva variable de configuración Open_verb_for__files permite que se cambie el intérprete predeterminado para los scripts con una extensión ext que se pueda cambiar. Para obtener más información, consulte la Sección 6.2.6 en la página . · La nueva variable de configuración CCB_Address configura un demonio para usar uno o más servidores CCB para permitir la comunicación con los componentes del cóndol fuera de la red privada. Consulte la página . · La nueva variable de configuración MAX_FILE_DESIPTORS (solo en plataformas UNIX) especifica el límite de descriptor de archivo requerido para un demonio condor. Los descriptores de archivos son un recurso del sistema utilizado para archivos abiertos y para conexiones de red. Los demonios del cóndor que hacen que muchas conexiones de red simultáneas pueden requerir un mayor número de descriptores de archivos. Por ejemplo, consulte la página para obtener información sobre los requisitos del descriptor de archivos de CCB. · Las nuevas variables de configuración enforce_cpu_affinity y slotx_cpu_affinity en las plataformas Linux permiten a Condor bloquear las ranuras a las CPU dadas. · La nueva variable de configuración Debug_time_Format permite una especificación personalizada para el formato del tiempo impreso al inicio de cada línea en el archivo de registro del demonio. Consulte 3.3.4 para la definición completa de esta variable. · La nueva variable de configuración Share_Spooled_Executables es un valor booleano que determina si el Daemon de Condor_Schedd utilizará las sumas de verificación MD5 para evitar almacenar múltiples copias del mismo ejecutable en el directorio Spool. La configuración predeterminada es verdadera.

Cóndor Software relacionado