Cron superado: ¿cuál es el próximo planificador? [cerrado]

Hemos estado usando cron durante aproximadamente el tiempo que puedo recordar para manejar todas nuestras necesidades de programación de trabajo. Todo, desde clones / instantáneas de almacenamiento hasta informes contra bases de datos, informes diarios del sistema y verificaciones de monitoreo, se programa en varios cientos de servidores a través de cron.

Los inconvenientes son bastante obvios: trabajos difíciles de administrar, no hay una manera fácil de crear dependencias (especialmente en diferentes servidores) y, por supuesto, es inevitable que alguien omita un trabajo "temporalmente" pero luego se olvide de eliminar el comentario.

Intentamos una oferta comercial, pero al final se consideró demasiado caro como un paso adelante del cron.

Veo otras opciones, como SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor, que parecen estar orientadas a entornos de clúster más grandes y más homogéneos con trabajos que se ejecutarían en cualquier número de nodos similares: computación en cuadrícula y similares. Nuestro entorno es bastante mixto (varios Linux, AIX y FreeBSD), y necesitamos crear dependencias en diferentes tipos de sistemas (por ejemplo, un trabajo en un cuadro de Linux puede necesitar determinar si un trabajo en un cuadro de AIX debería ejecutarse).

¿Alguien tiene alguna experiencia para pasar de cron a una oferta administrada más centralmente? ¿Algún consejo para elegir el software o si es mejor ir a código abierto o comercial?

Condor, OGE y Torque pueden llevarte allí, pero solo Condor tiene una gestión de dependencia incorporada con su herramienta DAGMan . DAGMan le permite configurar un gráfico dirigido y acíclico que describe su flujo de trabajo y el gerente se encarga de pasar por los trabajos en su flujo de trabajo y evaluar los resultados de aprobación / reprobación en cada paso del flujo. Condor es relativamente independiente de la plataforma, lo que significa que DAGMan también lo es, y ciertamente puede ejecutar un paso secundario en AIX cuando el padre se ejecuta en Linux o Windows. A DAGMan no le preocupa dónde se ejecutan los trabajos, solo que los códigos de salida son aprobados o no.

¿Algún consejo para elegir el software o si es mejor ir a código abierto o comercial?

Con algunas advertencias, creo que vale la pena mirar las comunidades libres en este espacio.

OGE está en un espacio extraño ahora. Ya no es gratis ejecutar la variante GE producida por Oracle y Oracle ya no está contribuyendo con el código que escribe en el SCC de GE, pero existen varias bifurcaciones del código que están tratando de convertirse en proyectos gratuitos y de código abierto. Univa en particular ha liderado la carga , contratando a ex desarrolladores de GE de Sun para que continúen trabajando en una variante de GE de código abierto y de libre acceso. Grid Engine tiene dos cosas: es fácil de configurar, puede manejar trabajos de ejecución corta (<2 minutos) sin impartir mucha sobrecarga de programación en los trabajos que ralentizan el rendimiento. Su gran inconveniente es que no hay muy buen soporte para Windows. Algunos de nosotros pusimos algunos esfuerzos en portarlo para que se ejecute en Cygwin hace muchos años, pero no es tan bueno como nativo, eso es seguro.

Ahora Condor es mi favorito de las tres tecnologías que mencionaste. Hay una comunidad fuerte alrededor de Condor y el software es muy maduro (> 20 años ahora). El soporte nativo para Windows y POSIX OS significa que funciona muy bien en todo el lugar. El mencionado DAGMan es solo una de las muchas piezas geniales que vienen con Condor. Puede ser un toque complicado de configurar, pero una vez que está en funcionamiento es sólido como una roca. Tiene un lenguaje increíblemente flexible para hacer trabajos <-> coincidencia de máquinas y construir sus reglas de uso para sus recursos. También admite el aprovisionamiento dinámico en máquinas, permitiendo que los trabajos seleccionen la cantidad de recursos de máquinas que necesitan y luego vuelvan a anunciar la diferencia como aún disponible. Admite contadores de recursos globales para que pueda restringir contra cosas como las licencias de software. Y por supuesto, tiene DAGMan, que es una herramienta increíblemente poderosa para la gestión del flujo de trabajo. La desventaja de Condor es que la sobrecarga de programación para trabajos cortos puede ser onerosa. Lo ideal es que los trabajos se ejecuten más de 2 minutos, de lo contrario la programación comienza a convertirse en una gran parte del tiempo del trabajo en el sistema.

El par es un poco más nicho. Sé menos al respecto, me temo. Se compara más con Grid Engine que Condor. Hay complementos pagos que @warren mencionó que pueden expandir lo que puede hacer el Torque básico y gratuito.

Si desea probar las tres tecnologías y ver cómo funcionan con sus cargas de trabajo específicas, CycleCloud puede crear agrupaciones seguras y virtualizadas que están preconfiguradas con Condor, GridEngine o Torque, por lo que no tiene que dedicar tiempo a resolverlo. de su parte. Se necesitarían unos pocos dólares para combinar pequeños grupos de cada tecnología y probarlos con cargas de trabajo representativas. (Descargo de responsabilidad: trabajo para Cycle Computing, hacemos CycleCloud)

Chronos se ve muy prometedor.

Chronos es el reemplazo de Airbnb para cron. Es un programador distribuido y tolerante a fallas que se ejecuta sobre Apache Mesos. Puede usarlo para organizar trabajos. Admite ejecutores de Mesos personalizados, así como el ejecutor de comandos predeterminado. Por lo tanto, por defecto, Chronos ejecuta scripts sh (en la mayoría de los sistemas bash). Chronos se puede utilizar para interactuar con sistemas como Hadoop (incluido EMR), incluso si los esclavos de Mesos en los que se ejecuta no tienen instalado Hadoop. Los scripts de envoltura incluidos permiten transferir archivos y ejecutarlos en una máquina remota en segundo plano y usar devoluciones de llamada asincrónicas para notificar a Chronos sobre la finalización del trabajo o fallas.

También he tenido un gran éxito personal con Jenkins como reemplazo de cron. Maneja la ejecución de trabajos en servidores remotos bastante bien. Aquí hay una reseña sobre ella: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/

Durante los últimos 4.5 años, he trabajado con la plataforma de automatización de servidores de HP (nee Opsware) y el resto del paquete de Business Technology Optimization (automatización de redes, organización de operaciones, etc.).

Para un entorno lo suficientemente grande, la gestión del trabajo a través de SA es una herramienta altamente viable (y deseable). En conjunto con OO, los trabajos se pueden controlar a través de la gestión de control de cambios, emisión de boletos, etc.

Aquí está la parte no tan divertida: es caro (muy caro). Puede consultar algunas de las sugerencias en una pregunta similar que le hice hace un tiempo: herramientas de administración y auditoría del servidor FLOSS .

También me gustaría decir que el par / Maui / Moab (de adaptación Computing ) están muy cool: no está seguro sobre los precios, pero son herramientas muy flexibles también.

NOTA ¡ Una visión completamente diferente del problema!

cron es viejo y torpe en ciertos términos.

Si realmente está buscando nuevas formas de programar, probaría algo basado en un middleware de mensajería. Piense en RabbitMQ con clientes en cada servidor.

Las dependencias entre hosts pueden resolverse mediante "colas de notificaciones".

Los eventos basados ​​en tiempo "real" son un poco más complicados, para eso es en realidad para qué sirve cron (y es bastante bueno, al menos en entornos pequeños). Donde es difícil hacerse con la idea es evitar los problemas. Como en: todas las noches a las 0100h hacer una instantánea. Es posible que vea algunos picos de carga o muchos inicios de sesión fallidos en ese mismo momento a través de toda su infraestructura. Si tiene un enfoque basado en la cola, obtendrá al menos alguna desviación de forma gratuita (aunque no está garantizado, a menos que alguna lógica lo implemente).

Lo que debe evitarse es que sin trabajos basados ​​en tiempo real no puede confiar en cosas como: sí, mis copias de seguridad comenzarán a las 0200h y si todavía se ejecutan a las 0400h, algo está mal. Lo más fácil es asegurarse de que no se ejecuten 2 trabajos que interfieran al mismo tiempo. Simplemente haga un agente de bloqueo que solo consuma un trabajo a la vez.

La parte de gestión sería una interfaz web agradable en la que los trabajos se pueden enviar a pedido, o, ahora vuelve a "cron" o su implementación favorita, el planificador de cuarzo java tiene una granularidad en segundos AFAIK - para el parte basada en el tiempo solo usa un buen cron :)

Por favor, no me denigren por ser OT: es un concepto bastante tosco, pero dado que la pregunta no excluye el dinero, es mejor gastar el dinero para obtener la solución para los requisitos internos exactos creando algo en lugar de gastar el dinero comprando algo donde un vendedor piensa que cumple algunos requisitos :)

He usado Espresso (Cybermation) de CA. No estoy seguro de cómo lo llaman ahora. También he usado UC4. Ambos funcionan, cuestan mucho dinero (según tengo entendido) y pueden ser un oso para mantener, pero hacen lo que dice. / Editar: omitió decir que las aplicaciones comerciales son demasiado caras. Definitivamente puedo estar de acuerdo, pero para algunas empresas, vale la pena, especialmente cuando se trata de aplicaciones comerciales que hacen dinero.

He trabajado con el Programador de trabajos de código abierto como una opción para reemplazar un crontab central de más de 2000 líneas en un entorno de producción. Las cosas se complicaron tanto con cron, que no pudimos determinar qué ventanas de tiempo de inactividad eran o cómo lidiar con las dependencias entre servidores. Este producto ayudó, pero fue un poco complejo de configurar.