1. Introduzione

I log di recupero informazioni sono un importante servizio per la computazione distribuita che dovrebbe essere sempre fornito con il sistema operativo. Tuttavia un puro e semplice adattamento del servizio di log management fornito dai tradizionali database, non è adeguato per un servizio di log che deve essere condiviso da più gestori di risorse.

Come esempio porteremo il sistema QuickSilver sviluppato da IBM [9].

2. Log

I log di recupero, sono importanti nel FT perché essi sono utilizzati da coordinatori di transazioni e gestori di risorse transazionali per tenere in memoria record sicuri contenenti le informazioni che servono per garantire le proprietà (ACID) delle transazioni. Infatti permettono la presenza permanente dei dati anche in caso di caduta di nodi o comunicazioni.

Inoltre le tecniche di recupero basate sui log, permettono il recupero parziale, anche in caso di catastrofi che cancellano tutte le copie esistenti dei dati.

Inoltre il FT si può implementare aggiungendo la replicazione dei dati e/o transazioni innestate una dentro l’altra.

I programmatori che scrivono applicazioni FT distribuite, che utilizzano le tradizionali risorse transazionali, non scrivono alcun codice speciale, ma solo si adattano alla struttura transazionale già esistente.

La robustezza è uno dei vantaggi del meccanismo basato sui log, perché essi sono una forma stabile di memorizzazione che sopravvive alla distruzione dei singoli nodi. Anche in presenza di disastri che distruggono completamente i dati, si può ancora ottenere una copia consistente, sebbene non completamente aggiornata di tutti i dati.

Ad un livello basso di FT, si possono aggiungere al proprio OS distribuito, le funzioni comuni ad un management di transazioni. Ogni gestore di risorse (per file system, DB manager, object store, monitor di processi remoti) può essere sviluppato e amministrato indipendentemente dagli altri, ma non mancano le sovrapposizioni (ad esempio un DBMS su un file system...).

Le applicazioni FT compongono le operazioni su multipli manager di risorse, come transazioni. Questa composizione deve essere stabilita in fase di design, così da garantire la consistenza tra tutti i gestori.

Inoltre il management di transazioni, offre miglioramenti rispetto ai manager di ogni singola risorsa: il servizio di log migliora la performance sia delle transazioni distribuite, che di quelle locali (più veloci) che accedano a manager di risorse. La coordinazione tra commit riduce inoltre il numero di messaggi che devono essere mandati tra i nodi per un commit distribuito.

Logicamente, i log di recupero usati nei DB, sono sequenze di record registrati in una memoria stabile (per un maggiore dettaglio v. Cap Tolleranza ai guasti nelle Basi di Dati).

Sebbene ci sono vantaggi nell’inserire un comune servizio di log in un sistema operativo, questa architettura pone dei problemi. Il primo è dovuto ai vari algoritmi di recupero dei vari manager di risorse, che possono rendere il log non interpretabile univocamente. Secondariamente il log condiviso deve proteggere sé stesso da design indipendenti e modifiche da parte degli amministratori di log locali che lo possono rendere inconsistente (ogni client locale ha le proprie risorse e le proprie richieste); quindi il servizio di log condiviso deve avere uno spazio di indirizzamenti che deve essere separato dai locali manager di risorse. Questa separazione crea un problema di caduta della performance per le scritture nel log: una scrittura bufferizzata aggiunge un nuovo record al buffer di memoria volatile e ritorna un LSN (log sequence number) che sarà utilizzato per un successivo recupero del contenuto. I normali manager di log in un DBMS utilizzano il byte di indirizzo relativo, come LSN, il che porta a letture molto efficienti. Tuttavia questo porta, in un SO con separato spazio di indirizzamento, ad un overhead (che in alcuni sistemi può essere notevole) dovuto alle comunicazioni tra processi e alle chiamate incrociate. Se per risolvere questo problema si inserisce la gestione dei buffer nei gestori di risorse, questo rende complicata l’assegnazione dei LSN e l’implementazione delle operazioni di lettura.

Inoltre lo spazio di logging è una risorsa condivisa non infinita. É possibile riutilizzare lo spazio quando i gestori delle risorse indicano che i dati di log non sono più necessari per il recupero o quando sono stati archiviati offline. Tuttavia gli indipendenti manager di risorse, possono non lasciare il log prontamente, oppure possono non essere pronti quando c’è un meccanismo di reclamo dello spazio.

Il tutto perché i singoli gestori di risorse hanno diversi requisiti da soddisfare per i loro log.

3. Log Manager

Il Log Manager utilizzato nel sistema QuickSilver della IBM risolve tutti questi problemi: assegnamento dei LSN, spazio di log finito.

Il LM in questione lancia processi separati e comunica con tutti i client; esso non impone uno specifico algoritmo di recupero, ma ne propone alcuni tipologie. Invece di utilizzare i byte di indirizzamento, utilizza una sequenza ordinata di interi. Quando un gestore di risorse scrive un record, un numero è assegnato da una routine sempre attiva. I nuovi record sono inizialmente registrati nello spazio proprio del gestore, successivamente i record sono inviati nella memoria volatile del LM oppure forzati ad essere scritti sulla memoria stabile; quando un record è forzato ad essere scritto, allora vengono forzati tutti i record precedentemente inviati da quella risorsa al LM. Così un singolo FORCE provoca il commit generale di tutti i record di quella risorsa. É possibile inoltre attivare il two-phase-commit.

Il LM QuickSilver utilizza una combinazione di richieste di call back e di speciali archivi (e di filtri su di essi gestiti dai singoli gestori) per risolvere il problema dello spazio condiviso di log.

Inoltre esiste un archivio online per il recupero che contiene anche i record necessari per abortire le transazioni a lungo termine e per il recupero dei gestori che non rispondono da un certo periodo di tempo, e muove i record loro appartenenti nell’archivio liberando così spazio per il log.