Checkpoint dell'applicazione - Application checkpointing
Il checkpoint è una tecnica che fornisce la tolleranza agli errori per i sistemi informatici . Consiste essenzialmente nel salvare un'istantanea dello stato dell'applicazione , in modo che le applicazioni possano riavviarsi da quel punto in caso di errore . Ciò è particolarmente importante per le applicazioni a lunga esecuzione eseguite nei sistemi informatici soggetti a guasti.
Checkpoint nei sistemi distribuiti
Nell'ambiente di elaborazione distribuita , il checkpoint è una tecnica che aiuta a tollerare errori che altrimenti costringerebbero l'applicazione di lunga durata a riavviarsi dall'inizio. Il modo più semplice per implementare il checkpoint è arrestare l'applicazione, copiare tutti i dati richiesti dalla memoria in uno storage affidabile (ad esempio, file system parallelo ) e quindi continuare con l'esecuzione. In caso di errore, al riavvio dell'applicazione, non è necessario ricominciare da capo. Piuttosto, leggerà lo stato più recente ("il checkpoint") dalla memoria stabile ed eseguirà da quello. Sebbene sia in corso un dibattito sul fatto che il checkpoint sia il carico di lavoro I/O dominante sui sistemi di elaborazione distribuiti, vi è consenso generale sul fatto che il checkpoint sia uno dei principali carichi di lavoro I/O.
Ci sono due approcci principali per il checkpoint nei sistemi informatici distribuiti: checkpoint coordinato e checkpoint non coordinato. Nell'approccio del checkpoint coordinato, i processi devono garantire che i loro checkpoint siano coerenti. Questo di solito è ottenuto da un qualche tipo di algoritmo del protocollo di commit a due fasi . Nel checkpoint non coordinato, ogni processo controlla il proprio stato in modo indipendente. Va sottolineato che la semplice forzatura dei processi a controllare il loro stato a intervalli di tempo fissi non è sufficiente per garantire la coerenza globale. La necessità di stabilire uno stato coerente (cioè, nessun messaggio mancante o messaggi duplicati) può costringere altri processi a tornare ai loro punti di controllo, il che a sua volta può causare il ritorno di altri processi a punti di controllo ancora precedenti, che nel caso più estremo può significa che l'unico stato coerente trovato è lo stato iniziale (il cosiddetto effetto domino ).
Implementazioni per applicazioni
Salva stato
Uno dei mezzi originali e ora più comuni di checkpoint dell'applicazione era una funzione di "salva stato" nelle applicazioni interattive, in cui l'utente dell'applicazione poteva salvare lo stato di tutte le variabili e altri dati su un supporto di memorizzazione nel momento in cui stavano utilizzando it e continuare a lavorare, oppure uscire dall'applicazione e, in un secondo momento, riavviare l'applicazione e ripristinare lo stato salvato. Ciò è stato implementato tramite un comando "salva" o un'opzione di menu nell'applicazione. In molti casi è diventata pratica standard chiedere all'utente se aveva del lavoro non salvato quando si esce dall'applicazione se voleva salvare il proprio lavoro prima di farlo.
Questo tipo di funzionalità è diventato estremamente importante per l'usabilità in applicazioni in cui il particolare lavoro non può essere completato in una sola seduta (come giocare a un videogioco che richiede dozzine di ore, o scrivere un libro o un lungo documento pari a centinaia o migliaia di pagine ) o dove il lavoro è stato svolto per un lungo periodo di tempo, ad esempio l'inserimento di dati in un documento come le righe in un foglio di calcolo.
Il problema con lo stato di salvataggio è che richiede all'operatore di un programma di richiedere il salvataggio. Per i programmi non interattivi, inclusi i carichi di lavoro automatizzati o elaborati in batch, anche la capacità di eseguire il checkpoint di tali applicazioni doveva essere automatizzata.
Punto di controllo/riavvio
Poiché le applicazioni batch hanno iniziato a gestire da decine a centinaia di migliaia di transazioni, in cui ogni transazione potrebbe elaborare un record da un file rispetto a diversi file diversi, la necessità per l'applicazione di essere riavviata a un certo punto senza la necessità di rieseguire l'intero lavoro da zero diventato imperativo. Nasce così la funzionalità di "checkpoint/restart", in cui dopo l'elaborazione di un certo numero di transazioni, è possibile acquisire uno "snapshot" o un "checkpoint" dello stato dell'applicazione. Se l'applicazione ha avuto esito negativo prima del checkpoint successivo, potrebbe essere riavviata fornendo le informazioni sul checkpoint e l'ultima posizione nel file della transazione in cui una transazione è stata completata con successo. L'applicazione potrebbe quindi riavviarsi a quel punto.
Il checkpoint tende ad essere costoso, quindi generalmente non veniva eseguito con ogni record, ma con un ragionevole compromesso tra il costo di un checkpoint e il valore del tempo del computer necessario per rielaborare un batch di record. Pertanto, il numero di record elaborati per ogni punto di controllo può variare da 25 a 200, a seconda dei fattori di costo, della complessità relativa dell'applicazione e delle risorse necessarie per riavviare correttamente l'applicazione.
Interfaccia di tolleranza agli errori (FTI)
FTI è una libreria che mira a fornire agli scienziati computazionali un modo semplice per eseguire checkpoint/riavvio in modo scalabile. FTI sfrutta lo storage locale e più tecniche di replica e cancellazione per fornire diversi livelli di affidabilità e prestazioni. FTI fornisce un checkpoint a livello di applicazione che consente agli utenti di selezionare quali dati devono essere protetti, al fine di migliorare l'efficienza ed evitare sprechi di spazio, tempo ed energia. Offre un'interfaccia dati diretta in modo che gli utenti non debbano occuparsi di file e/o nomi di directory. Tutti i metadati sono gestiti da FTI in modo trasparente per l'utente. Se lo si desidera, gli utenti possono dedicare un processo per nodo per sovrapporre il carico di lavoro di tolleranza agli errori e il calcolo scientifico, in modo che le attività post-checkpoint vengano eseguite in modo asincrono.
Punto di controllo/riavvio del laboratorio di Berkeley (BLCR)
Il Future Technologies Group presso i Lawrence National Laboratories sta sviluppando un'implementazione ibrida kernel/utente di checkpoint/restart chiamata BLCR. Il loro obiettivo è fornire un'implementazione robusta e di qualità della produzione che controlli un'ampia gamma di applicazioni, senza richiedere modifiche al codice dell'applicazione. BLCR si concentra sul checkpoint di applicazioni parallele che comunicano tramite MPI e sulla compatibilità con la suite software prodotta da SciDAC Scalable Systems Software ISIC. Il suo lavoro è suddiviso in 4 aree principali: Checkpoint/Restart per Linux (CR), Librerie MPI Checkpointable, Interfaccia di gestione delle risorse per Checkpoint/Restart e Sviluppo di interfacce di gestione dei processi.
DMTCP
DMTCP (Distributed MultiThreaded Checkpointing) è uno strumento per il checkpoint trasparente dello stato di un gruppo arbitrario di programmi distribuiti su molte macchine e connessi tramite socket. Non modifica il programma dell'utente o il sistema operativo. Tra le applicazioni supportate da DMTCP ci sono Open MPI , Python , Perl e molti linguaggi di programmazione e linguaggi di scripting della shell. Con l'uso di TightVNC, può anche eseguire il checkpoint e riavviare le applicazioni X Window, purché non utilizzino estensioni (ad es. niente OpenGL o video). Tra le funzionalità di Linux supportate da DMTCP ci sono descrittori di file aperti , pipe, socket, gestori di segnale, virtualizzazione di ID di processo e ID di thread (assicurati che i vecchi pid e tid continuino a funzionare al riavvio), ptys, fifos, ID di gruppi di processi, ID di sessione, terminale attributi e mmap /mprotect (inclusa la memoria condivisa basata su mmap). DMTCP supporta l'API OFED per InfiniBand in via sperimentale.
Checkpoint collaborativo
Alcuni protocolli recenti eseguono il checkpoint collaborativo memorizzando frammenti del checkpoint nei nodi vicini. Ciò è utile perché evita il costo dell'archiviazione in un file system parallelo (che spesso diventa un collo di bottiglia per i sistemi su larga scala) e utilizza l'archiviazione più vicina. Questo ha trovato impiego in particolare nei cluster di supercalcolo su larga scala. La sfida consiste nell'assicurare che quando il checkpoint è necessario durante il ripristino da un errore, i nodi vicini con frammenti dei checkpoint siano disponibili.
Docker
Docker e la tecnologia sottostante contengono un checkpoint e un meccanismo di ripristino.
CRIU
CRIU è una libreria di checkpoint dello spazio utente.
Implementazione per dispositivi embedded e ASIC
Ricordi
Mementos è un sistema software che trasforma attività generiche in programmi interrompibili per piattaforme con interruzioni frequenti come interruzioni di corrente. È stato progettato per dispositivi embedded senza batteria come tag RFID e smart card che si basano sulla raccolta di energia da fonti ambientali di fondo. Mementos rileva frequentemente l'energia disponibile nel sistema e decide se eseguire il checkpoint del programma a causa dell'imminente perdita di potenza rispetto al calcolo continuo. In caso di checkpoint, i dati verranno archiviati in una memoria non volatile . Quando l'energia diventa sufficiente per il riavvio , i dati vengono recuperati dalla memoria non volatile e il programma riprende dallo stato memorizzato. Mementos è stato implementato sulla famiglia di microcontrollori MSP430 . Mementos prende il nome di Christopher Nolan 's Memento .
Idetico
Idetic è un insieme di strumenti automatici che aiuta gli sviluppatori di circuiti integrati (ASIC) specifici dell'applicazione a incorporare automaticamente i checkpoint nei loro progetti. Si rivolge a strumenti di sintesi di alto livello e aggiunge i checkpoint a livello di trasferimento del registro ( codice Verilog ). Utilizza un approccio di programmazione dinamica per individuare punti di overhead bassi nella macchina a stati del progetto. Poiché il checkpoint a livello hardware comporta l'invio dei dati dei registri dipendenti a una memoria non volatile, è necessario che i punti ottimali abbiano un numero minimo di registri da memorizzare. Idetic viene distribuito e valutato sul dispositivo tag RFID per la raccolta di energia .
Guarda anche
Riferimenti
Ulteriori letture
- Yibei Ling, Jie Mi, Xiaola Lin: un approccio di calcolo variazionale al posizionamento ottimale del punto di controllo. IEEE Trans. Computer 50(7): 699-708 (2001)
- RE Ahmed, RC Frazier e PN Marinos, "Algoritmi di ripristino degli errori di ripristino della cache (CARER) per sistemi multiprocessore a memoria condivisa", IEEE 20th International Symposium on Fault-Tolerant Computing (FTCS-20), Newcastle upon Tyne, Regno Unito, 26-28 giugno 1990, pp. 82-88.
