Replicazione. Requisisti di consistenza i clienti devono ricevere risposte consistenti e coerenti. Motivazioni

Transcript

1 Replicazione Replicazione dei dati: gestione e manutenzione di un insieme di copie dei dati Motivazioni: - disponibilità - tolleranza ai guasti - prestazioni aching diverso da replicazione aching non aumenta necessariamente la disponibilità Requisiti di trasparenza di replicazione i clienti ignorano l esistenza di copie fisiche multiple, interagiscono come con un unico servente Requisisti di consistenza i clienti devono ricevere risposte consistenti e coerenti Motivazioni Disponibilità: del servizio realizzato da un insieme di serventi che replicano dati e funzionalità - gestione dei guasti dei server - partizione della rete e gestione delle disconnessioni Per N server e p probabilità di guasto di ogni server, sotto ipotesi di indipendenza dei guasti, la disponibilità (Availability) è 1-p N Tolleranza ai guasti: garantisce dati corretti e aggiornati anche in caso di guasti, replica dati e funzionalità Per un numero di guasti bizantini fino a G occorre avere un numero di serventi di almeno (2G+1) per garantire il risultato corretto con meccanismi di votazione Eventualmente sono necessari anche meccanismi di coordinamento Prestazioni: caching di dati ai serventi e ai clienti Per dati stabili la replicazione è gestibile in modo semplice Per dati variabili occorre introdurre protocolli che garantiscano la consistenza -> overhead

2 Modelli di sistemi Insieme di oggetti logici oggetto logico onsistenza delle copie oggetto fisico replica 1 oggetto fisico replica 2 oggetto fisico replica N Insieme di oggetti fisici Sistema distribuito asincrono soggetto a guasti Assumiamo che non esista partizione di rete Replica Manager: componente sw che contiene copie e le gestisce in un modello cliente-servente è un servente gestisce gli errori non lascia risultati inconsistenti 14.3 Modello architetturale di base per la gestione dei dati replicati Requests e replies lienti Front ends Service Replica managers

3 Replica manager Operazioni richieste dai clienti - invocazioni su uno o più oggetti read only request update request Passi di gestione di una richiesta su un sistema con replicazione 1. omunicazione {} comunicazione con uno o più comunicazione multicast 2. oordinamento per la consistenza si decide se applicare la richiesta e con quale ordine FIFO - causale - totale 3. Esecuzione della richiesta su un eventuale tentativo, annullabile 4. Accordo fra sugli effetti della esecuzione della richiesta 5. Risposta al cliente {} uno o più rispondono, eventualmente tramite 14.5 Gestione dei gruppi Gruppi e comunicazione Gruppi statici vs dinamici Servizio di appartenenza al gruppo (group membership service) - fornisce una interfaccia per gestire le modifiche al gruppo e crazione/elim. gruppo - implementa un rilevatore di guasti che marca processi sospetti e non - notifica le variazioni del gruppo ai membri del gruppo - esegue l espansione dell indirizzamento di gruppo Un processo sospetto può ridurre l efficienza group view lista dei membri del gruppo corrente con gli identificatori di processo view delivery - consegna di una vista un membro consegna una vista se vi è una modifica di appartenenza e viene notificata alla applicazione Un evento può avvenire in una view v(g) al processo p del gruppo g, se al tempo di occorrenza dell evento, p ha consegnato v(g) come ultima vista

4 View delivery Requisiti - ordine delle viste da parte di tutti i processi - integrità se p consegna la vista v(g), allora p appartiene alla v(g) - non banalità se q entra nel gruppo, è o diventa raggiungibile da p ovvero p e q possono comunicare omunicazione a gruppi view-synchronous Aggiunge una garanzia di ordinamento di notifica rispetto alla consegna di messaggi multicast Estende la semantica di multicast affidabile considerando le modifiche di vista del gruppo - accordo consegna dello stesso insieme di messaggi in ogni vista - integrità se p consegna un messaggio, non lo ripeterà - validità i processi consegnano sempre i messaggi inviati; se un processo q non ha consegna del messaggio, il sistema lo notifica e successive viste escludono q 14.7 Servizi forniti a gruppi di processi Espansione dell ndirizzo del gruppo Group send omunicazione multicast Leave Fail Gestione dell appartenenza al gruppo Gruppo di processi Join

5 omunicazione a gruppo con vista sincronizzata a (allowed). p p crashes b (allowed). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) c (disallowed). p p crashes d (disallowed). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) 14.9 Modello passivo (primary-backup) di tolleranza ai guasti Primary ackup ackup

6 Repliche attive Operazioni di query e update in un servizio gossip Servizio gossip Query, prev Val, new Update, prev Update id Query Val lienti Update

7 Front end inoltrano i loro timestamps se un cliente comunica direttamente Servizio gossip Vector timestamps lienti Gestore di replica gossip: componenti di stato principali Altri replica managers Replica timestamp Replica log messaggi gossip Replica manager Timestamp table Replica timestamp Update log Stable updates Value timestamp Value Executed operation table Updates OperationID Update Prev

8 Transazioni su dati replicati T U deposit(,3); getalance(a) A A A opie disponibili T U getalance(a) deposit(,3); M getalance() deposit(a,3); X A Y A P N

9 Partizione della rete withdraw(, 4) T Partizione della rete deposit(,3); U Gestione della partizione Guasti riparabili Recupero della consistenza Approccio ottimistico ammette la scrittura in tutte le partizioni verifica la consistenza al recupero copie disponibili uso di vettori di versione per write Approccio pessimistico previene l inconsistenza durante la partizione quorum consensus una sola partizione può operare; ogni partizione decide se può Approccio combinato algoritmo di partizione virtuale

10 Partizioni di due reti Transazione T Partizioni di rete X V Y Z Partizione virtuale Partizione virtuale Partizione di rete X V Y Z

11 Due partizioni virtuali sovrapposte Partizione virtuale V 1 Partizione virtuale V 2 Y X V Z reare una partizione virtuale Fase 1: L iniziatore invia una richiesta di Join ad ogni membro potenziale. L argomento della Join è un timestamp logico proposto per la nuova partizione virtuale Quando un replica manager riceve una richiesta di Join, confronta il timestamp logico proposto con quello della sua partizione virtuale corrente se il timestamp logico proposto è maggiore, accetta di unirsi e risponde Yes se è minore, rifiuta e risponde No. Fase 2: Se l iniziatore ha ricevuto un numero sufficiente di risposte Yes risponde di avere read e write quora, può completare la creazione di una nuova partizione virtuale mandando un messaggio onfirmation ai nodi che hanno aderito Il timestamp di creazione e la lista dei membri effettivi sono inviati come argomenti I replica managers che ricevono il messaggio onfirmation si uniscono alla nuova partizione virtuale e registrano il suo timestamp di creazione e la lista dei membri effettivi