Cron in crescita: qual è il prossimo programmatore? [chiuso]

Usiamo cron da circa il tempo che ricordo di gestire tutte le nostre esigenze di pianificazione del lavoro. Tutto, dai cloni di archiviazione / istantanee ai report contro i database ai report di sistema giornalieri ai controlli di monitoraggio sono programmati su alcune centinaia di server tramite cron.

Gli svantaggi sono piuttosto evidenti: lavori difficili da gestire, nessun modo semplice per creare dipendenze (soprattutto tra server diversi) e, naturalmente, è inevitabile che qualcuno salti "temporaneamente" un lavoro, ma in seguito si dimentica di rimuovere il commento.

Abbiamo provato un'offerta commerciale, ma alla fine è stata considerata troppo costosa come un passo avanti rispetto a cron.

Vedo altre opzioni là fuori, come SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor che sembrano orientati verso ambienti cluster più grandi e omogenei con lavori che verrebbero eseguiti su un numero qualsiasi di nodi simili: grid computing e simili. Il nostro ambiente è piuttosto misto (vari Linux, AIX e FreeBSD) e dobbiamo creare dipendenze tra diversi tipi di sistemi (ad es. Un lavoro su un box Linux potrebbe dover determinare se dovrebbe essere eseguito un lavoro su un box AIX).

Qualcuno ha qualche esperienza di passaggio da cron a un'offerta gestita più centralmente? Qualche consiglio per scegliere il software o se è meglio andare open source o commerciale?

Condor, OGE e Torque possono portarti tutti lì, ma solo Condor ha una gestione delle dipendenze integrata con il suo strumento DAGMan . DAGMan consente di impostare un grafico aciclico diretto che descrive il flusso di lavoro e il manager si occupa di spostarsi tra i lavori nel flusso di lavoro e valutare i risultati di superamento / fallimento in ogni fase del flusso. Condor è relativamente indipendente dalla piattaforma, il che significa che lo è anche DAGMan, e puoi sicuramente avere un passo secondario eseguito su AIX quando il genitore funzionava su Linux o Windows. DAGMan non si occupa di dove vengono eseguiti i lavori, solo che i codici di uscita vengono passati o falliti.

Qualche consiglio per scegliere il software o se è meglio andare open source o commerciale?

Con alcuni avvertimenti, penso che valga la pena guardare le comunità libere in questo spazio.

OGE è in uno spazio strano adesso. Non è più gratuito eseguire la variante GE prodotta da Oracle e Oracle non sta più contribuendo con il codice che riscrive in GE SCC, ma esistono diverse fork del codice che stanno tentando di aggredire come progetti open source gratuiti. Univa in particolare ha guidato la carica , assumendo gli ex sviluppatori Sun GE per continuare a lavorare su una variante GE open source, liberamente disponibile. Grid Engine ha due cose da fare: è facile da configurare, è in grado di gestire lavori di breve durata (<2 minuti) senza impartire molto overhead di pianificazione ai lavori che rallentano la produttività. Il suo grande svantaggio è che non c'è un ottimo supporto per Windows. Alcuni di noi hanno fatto alcuni sforzi per portarlo su Cygwin molti anni fa, ma non è sicuro come quello nativo.

Ora Condor è la mia preferita delle tre tecnologie che hai citato. C'è una forte comunità attorno a Condor e il software è molto maturo (> 20 anni ormai). Il supporto nativo di Windows e POSIX significa che funziona molto bene ovunque. Il già citato DAGMan è solo uno dei tanti grandi pezzi di Condor. Può essere un tocco complicato da configurare, ma una volta installato e funzionante è solido come una roccia. Ha un linguaggio incredibilmente flessibile per fare corrispondenze di lavoro <-> macchine e costruire regole d'uso per le tue risorse. Supporta inoltre il provisioning dinamico sulle macchine, consentendo ai lavori di selezionare la quantità di risorse delle macchine di cui hanno bisogno e quindi ripubblicare la differenza come ancora disponibile. Supporta contatori di risorse globali in modo da poter vincolare cose come le licenze software. Ed ovviamente, ha DAGMan, che è uno strumento incredibilmente potente per la gestione del flusso di lavoro. L'aspetto negativo di Condor è il sovraccarico di pianificazione per i lavori di breve durata può essere oneroso. Volete lavori che durino più di 2 minuti idealmente, altrimenti la pianificazione inizia a diventare una grande parte del tempo del lavoro nel sistema.

La coppia è un po 'più di nicchia. Ne so meno, temo. Paragona più a Grid Engine che a Condor. Ci sono componenti aggiuntivi a pagamento citati da @warren che possono espandere ciò che la Torque base gratuita può fare.

Se vuoi provare le tre tecnologie e vedere come funzionano con i tuoi carichi di lavoro specifici, CycleCloud può creare pool sicuri, virtualizzati e preconfigurati con Condor, GridEngine o Torque, quindi non dedicare tempo a capire queste cose da parte tua. Sarebbero pochi dollari per creare piccoli pool di ogni tecnologia e provarli con carichi di lavoro rappresentativi. (Dichiarazione di non responsabilità: lavoro per Cycle Computing, creiamo CycleCloud)

Chronos sembra molto promettente.

Chronos è il sostituto di Airbnb per cron. È uno scheduler distribuito e tollerante agli errori che funziona su Apache Mesos. Puoi usarlo per orchestrare i lavori. Supporta gli esecutori Mesos personalizzati e l'esecutore di comando predefinito. Pertanto, per impostazione predefinita, Chronos esegue script sh (sulla maggior parte dei sistemi bash). Chronos può essere usato per interagire con sistemi come Hadoop (incl. EMR), anche se gli slave Mesos su cui avviene l'esecuzione non hanno Hadoop installato. Gli script wrapper inclusi consentono di trasferire file e di eseguirli su una macchina remota in background e di utilizzare callback asincroni per notificare a Chronos il completamento del lavoro o errori.

Ho anche avuto un grande successo personale usando Jenkins come sostituto del cron. Gestisce l'esecuzione dei lavori su server remoti abbastanza bene. Ecco un commento su di esso: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/

Negli ultimi 4,5 anni ho lavorato con la piattaforma di automazione server HP (nuova Opsware) e il resto della suite di ottimizzazione della tecnologia aziendale (automazione di rete, orchestrazione delle operazioni, ecc.).

Per un ambiente sufficientemente ampio, la gestione dei lavori tramite SA è uno strumento altamente fattibile (e desiderabile). In combinazione con OO, i lavori possono essere controllati tramite la gestione del controllo delle modifiche, l'emissione di biglietti, ecc.

Ecco la parte non così divertente: è costoso (molto costoso). È possibile verificare alcuni dei suggerimenti in una domanda simile che ho posto qualche tempo fa: strumenti di gestione e controllo del server FLOSS .

Direi anche che Torque / Maui / Moab (da Adaptive Computing ) sono molto interessanti : non sono sicuro dei prezzi, ma sono anche strumenti altamente flessibili.

NOTA Un approccio completamente diverso al problema!

cron è vecchio e goffo in certi termini.

Se stai davvero cercando nuovi modi per fare la pianificazione, proverei qualcosa di basato su un middleware di messaggistica. Pensa a RabbitMQ con i client su ciascun server.

Le dipendenze dell'Inter Host possono essere risolte mediante "code di notifica".

Gli eventi "Real" basati sul tempo sono un po 'più complicati, questo è in realtà il cron (ed è abbastanza bravo, almeno per quanto riguarda i piccoli ambienti). Dove è difficile riuscire a prendere in considerazione l'idea è di prevenire i singhiozzi. Come in: ogni notte alle 0100h fare un'istantanea. Potresti vedere alcuni picchi di carico o molti accessi non riusciti in quel preciso momento attraverso l'intera infrastruttura. Se hai un approccio basato su una coda otterrai almeno qualche deviazione gratuitamente (anche se non è garantito - a meno che una logica non lo implementi).

La cosa da aggirare è che senza lavori basati sul tempo reale non puoi fare affidamento su cose come: sì, i miei backup inizieranno alle 02:00 e se continuano a funzionare alle 04:00 qualcosa non va. La cosa più facile da fare è assicurarsi che non vengano eseguiti contemporaneamente 2 lavori che interferiscono. Basta creare un agente bloccante che consumerà solo un lavoro alla volta.

La parte di gestione sarebbe una bella interfaccia web in cui i lavori potrebbero essere inviati su richiesta, oppure - ora torna a "cron" o la tua implementazione preferita di esso lo scheduler al quarzo Java ha una granularità in secondi AFAIK - per il parte basata sul tempo basta usare un buon vecchio cron :)

Per favore, non mi sottovalutare per essere OT: è un concetto piuttosto approssimativo, ma poiché la domanda non esclude il denaro, si potrebbe anche spendere i soldi per ottenere la soluzione per gli esatti requisiti interni creando qualcosa piuttosto che spendere i soldi acquistando qualcosa in cui un venditore pensa che soddisfi alcuni requisiti :)

Ho usato Espresso (Cybermation) di CA. Non sono sicuro di come lo chiamino adesso. Ho anche usato UC4. Entrambi funzionano, costano un sacco di soldi (per la mia comprensione) e possono essere un orso da mantenere, ma fanno quello che dice sulla scatola. / Modifica: non hai detto che le app commerciali sono troppo costose. Sono assolutamente d'accordo, ma per alcune aziende ne vale la pena, soprattutto quando si tratta di applicazioni aziendali che fanno soldi.

Ho lavorato con il Job Scheduler Open Source come opzione per sostituire un crontab centrale 2000+ line in un ambiente di produzione. Le cose sono diventate così complicate con cron, che non siamo riusciti a determinare quali fossero i tempi di inattività di Windows o come gestire le dipendenze tra server. Questo prodotto ha aiutato, ma era un po 'complesso da configurare.