Open Grid Engine o Akka / Qualcosa di più tollerante ai guasti?

7

Il mio caso d'uso è che ho una pipeline di programmi indipendenti e autonomi, che voglio eseguire in un certo ordine su specifiche parti di dati che vengono emesse dai precedenti stadi della pipeline.

La pipeline è interamente lineare e non fa nulla in termini di percorsi alternativi attraverso la pipe.

Attualmente sto usando SGE per fare questo e funziona OK, tuttavia occasionalmente un lavoro supererà i suoi limiti di memoria, fallirà e tutti i lavori che richiedono che i dati di output falliscano. In questo caso la pipe deve essere riavviata e sembra che tutto ciò che fornisce la tolleranza ai guasti in akka potrebbe risolverlo per me?

    
posta Mike Lyons 15.11.2012 - 17:48
fonte

1 risposta

0

Ci sono molti modi per fornire tolleranza d'errore per il tuo servizio. Dipende in gran parte dal tuo caso d'uso, dalla tecnologia esistente che hai già e dal pervasivo ecosistema del tuo stack. Sta a te scegliere cosa usare e come combinarlo nel tuo codice. Akka è un framework enorme con molte funzionalità e, se lo utilizzi solo per fornire tolleranza , può essere eccessivo , ma, di nuovo, dipende dal tuo use case.

Nuovo tentativo

Il più ingenuo è quello di avvolgere il tuo lavoro in qualche strategia di riprova direttamente nel tuo codice , ad esempio qualcosa del tipo: Spring Retry . Questo potrebbe rilevare quando il tuo lavoro è fallito e riprovare.

Gestori risorse

Un altro approccio, non così ingenuo, sarebbe utilizzare un gestore di risorse come YARN , < a href="http://mesos.apache.org/"> Mesos , o qualche meccanismo di pianificazione come AWS Batch (considerando che stai usando SGE, probabilmente non è una buona idea). Tutte queste tecnologie potrebbero essere eccessive nel tuo caso d'uso, ma hanno ottime capacità in ambienti ad alta disponibilità, quindi sono soluzioni che vale la pena prendere in considerazione se stai inseguendo la scala .

Monitor dall'esterno

Un altro approccio potrebbe essere che ogni sottoprocesso riporta un controllo sanitario su un'istanza (chiamiamola un monitor) il cui unico scopo è monitorare lo stato della pipeline. Se un lavoro non supera alcuni controlli, l'istanza Monitor è responsabile del riavvio o del riavvio dell'intera pipe .

Questo sembra essere l'approccio più semplice e logico nel tuo caso d'uso, specialmente se lo combini con ogni stato di mantenimento del lavoro (o il tuo monitor che lo tiene per loro) , quindi se uno di essi fallisce, puoi riavviare la pipeline dal lavoro LAST completato con successo .

Se osservi una normale pipeline costruita in Hadoop su YARN, un approccio comune per ogni lavoro è ottenere il suo input da un PERCORSO in hdfs (dove mantieni il tuo stato), e il suo output è anche un PATH su hdf, quindi altri lavori possono prenderlo come input. YARN, che è il gestore delle risorse, si occupa dello stato dei lavori, dei progressi, degli errori, ecc. E dell'assegnazione delle risorse a quel lavoro. Questo suona simile al tuo caso SGE, è solo che probabilmente dovrai implementare alcuni (o molto del monitor + la logica dello stato). Se non ti preoccupi dello stato e stai bene riavviando la pipeline da zero , è molto più semplice in quanto hai solo due parti mobili molto semplici:

  • rileva quando un lavoro è fallito
  • riavvia l'intera pipeline
risposta data 14.12.2018 - 23:22
fonte

Leggi altre domande sui tag