Tecnica di riavvio rapido invece di mantenere il buono stato (disponibilità e coerenza)

Question

Con quale frequenza risolvi i tuoi problemi riavviando un computer, un router, un programma, un browser? O anche reinstallando il sistema operativo o il componente software?

Questo sembra essere un modello comune quando si sospetta che il componente software non mantenga il suo stato nel modo giusto, quindi si ottiene semplicemente lo stato iniziale riavviando il componente.

Ho sentito che Amazon / Google ha un cluster di molti nodi. E una proprietà importante di ciascun nodo è che può riavviarsi in pochi secondi. Quindi, se uno di essi fallisce, riportarlo allo stato iniziale è solo una questione di riavvio.

Esistono linguaggi / quadri / modelli di progettazione che sfruttano questa tecnica come cittadini di prima classe?

MODIFICA Il link che descrive alcuni principi alla base di Amazon, nonché i principi generali di disponibilità e coerenza: http://www.infoq.com/presentations/availability-consistency

Answer 1

Questo è comune nel mondo dei sistemi embedded e nelle telecomunicazioni. È molto meno comune nel mondo basato su server.

C'è un gruppo di ricerca che potrebbe interessarti. Hanno lavorato su Informatica orientata al recupero o "ROC". Il principio chiave in ROC è che lo stato più pulito, migliore e più affidabile in cui possa trovarsi un programma sia subito dopo l'avvio. Pertanto, al rilevamento di un errore, preferiscono riavviare il software piuttosto che tentare di ripristinare l'errore.

Sembra abbastanza semplice, giusto? Bene, gran parte della ricerca è andata a implementare quell'idea. Il motivo è esattamente ciò che tu e altri commentatori avete sottolineato: i riavvii del sistema operativo sono troppo lenti per essere un metodo di recupero praticabile.

ROC si basa su tre parti principali:

1. Un metodo per rilevare i guasti il ??più presto possibile.
2. Un mezzo per isolare il componente difettoso preservando il resto del sistema.
3. Si riavvia a livello di componente.

La vera differenza chiave tra ROC e il tipico "notturno riavvio" l'approccio è che ROC è una strategia in cui i riavvii sono una reazione. Ciò che intendo è che la maggior parte dei software è scritta con un certo grado di gestione e recupero degli errori (lancio e cattura, registrazione, ripetizione di cicli, ecc.) Un programma ROC rileverà l'errore (eccezione) e immediatamente esci. Mischiare i due paradigmi ti lascia solo con il peggio di entrambi i mondi: bassa affidabilità ed errori.

Answer 2

Questo è in realtà molto raro nel mondo unix / linux. Quelle dosi sono state progettate (e così pure le finestre) per proteggersi da processi mal comportati. Sono sicuro che Google non si affida a riavvii duri per correggere il software che si comporta male. Direi che questa tecnica non dovrebbe essere impiegata e se qualcuno dice che la via più difficile per il recupero del proprio software dovresti cercare qualcos'altro!

Answer 3

I microcontrollori in genere hanno un timer watchdog, che deve essere ripristinato (con una riga di codice) ogni tanto, altrimenti il ??microcontrollore verrà ripristinato. Ciò impedisce al firmware di rimanere bloccato in un ciclo infinito, bloccato in attesa di input, ecc.

La memoria inutilizzata viene talvolta impostata su un'istruzione che provoca un ripristino o un salto nella stessa posizione in cui il microcontrollore inizia quando viene ripristinato. Ciò ripristinerà il microcontrollore se in qualche modo salta in una posizione esterna alla memoria del programma.

Answer 4

I sistemi integrati possono avere una funzione di checkpoint in cui ogni n ms viene salvato lo stack corrente. La memoria non è volatile al riavvio dell'alimentazione (ad es. Alimentato a batteria), quindi all'avvio dell'alimentazione viene eseguito un test per verificare se il codice deve passare a un vecchio checkpoint o se si tratta di un sistema nuovo.

Immagino che una tecnica simile (ma più sofisticata) sia utilizzata per Amazon / Google.

Answer 5

Anche se non riesco a pensare a un modello di progettazione in sé, nella mia esperienza, è il risultato di " select is broken " dagli sviluppatori.

Ho visto un sito di 50 utenti paralizzare sia SQL Server Enterprise Edition (con un database da 750 MB) sia un server Novell a causa della cattiva gestione delle connessioni unita a chiamate eccessive e nessuna memorizzazione nella cache. Novell è stato sempre il colpevole secondo gli sviluppatori fino a quando non abbiamo trovato un "CloseConnection" mancante chiama in una libreria principale. A quel punto, migliaia furono spesi, senza successo, in aggiornamenti per affrontare quella riga di codice mancante.

(Perché avevano Enterprise Edition era oltre me, quindi non chiedermelo !!)

Answer 6

Se guardi i linguaggi di scripting come php in esecuzione su Apache, ogni invocazione avvia un nuovo processo. Nel caso di base non esiste uno stato condiviso tra i processi e una volta terminata l'invocazione, il processo viene terminato.

I vantaggi sono meno onus sulla gestione delle risorse in quanto verranno rilasciati al termine del processo e meno necessità di gestione degli errori poiché il processo è progettato per fallire rapidamente e non può essere lasciato in uno stato incoerente.

Answer 7

L'ho visto in alcuni punti a livello di applicazione (un'app che si riavvia da sola se bombarda).

Ho implementato il modello a livello di applicazione, in cui un servizio di lettura da file Dbase inizia a ricevere errori dopo aver letto x volte. Cerca un errore particolare che viene generato e se rileva tale errore, il servizio chiama un'app console che interrompe il processo e riavvia il servizio. È kludgey, e lo odio, ma per questa situazione particolare, non sono riuscito a trovare una risposta migliore.

E tieni presente che IIS ha una funzionalità integrata che riavvia il pool di applicazioni in determinate condizioni.

In ogni caso, il riavvio di un servizio è un'opzione per qualsiasi servizio su Windows come una delle azioni da intraprendere in caso di errore del servizio.