Durante la fase di progettazione di un sistema distribuito c’è un aspetto fondamentale da non sottovalutare. Il teorema CAP è stato formulato negli anni 2000 da Brewer (fondatore di Inktomi e chief scientist di Yahoo) afferma che è impossibile per un sistema distribuito fornire contemporaneamente tutte le tre seguenti proprietà: consistenza, disponibilità e tolleranza al partizionamento.

Elementi del teorema di CAP

I seguenti elementi costituiscono il nucleo del teorema.

Consistenza (Consistency)

Un sistema distribuito può essere considerato totalmente consistente quando è in grado di garantire che una volta memorizzato un nuovo stato, questo è utilizzato in ogni operazione successiva fino alla successiva modifica dello stesso. Nel periodo di transizione tra uno stato del sistema e il successivo, tutte le richieste per lo stato del sistema restituiscono lo stesso risultato.

In parole povere si riferisce alla capacità del sistema di garantire che tutti i nodi ricevano la stessa copia dei dati e che tali dati siano aggiornati in modo coerente in tutti i nodiQuesto problema non si presenta in sistemi con singolo nodo.

Il sistema è pienamente consistente quando tutti i nodi sono in grado di lavorare sullo stesso stato, ossia vedono gli stessi dati con gli stessi valori. Perché questo accada, ogni qualvolta i dati vengono scritti su un nodo, devono essere inoltrati o replicati su tutti gli altri nodi nel sistema prima che la scrittura sia considerata riuscita. Ovviamente tale operazione può essere onerosa.

Disponibilità (Availability)

Possiamo dire che un sistema distribuito è continuamente disponibile quando è sempre in grado di soddisfare le varie richieste/erogare i propri servizi.

Se prediamo in considerazione un sistema costituito da un singolo nodo, questo non può rispettare la proprietà in quanto è sufficiente che il nodo vada giù affinché il sistema non sia più disponibile. Ecco perchè in questo caso è necessario prevedere degli opportuni sistemi di tolleranza ai guasti tramite soluzioni ridondanti.

Aumentare il numero di nodi di un sistema comporta un aumento della disponibilità a sfavore della consistenza assistendo ad un degradamento delle performance.

Tolleranza al Partizionamento (Partition tolerance)

Un sistema che garantisce questa proprietà funziona correttamente anche in presenza di una serie di fallimenti dell’infrastruttura sottostante. Può succedere che qualche nodo del sistema può fallire, di conseguenza si possono creare delle partizioni del sistema che non comunicano tra di loro ma riescono a funzionare in modo indipendente e coerente al loro interno.

Quindi, con tolleranza alle partizioni si intende l’obbligo per il sistema di continuare a funzionare indipendentemente dal numero di interruzioni nelle comunicazioni tra i nodi nel sistema.

Cosa afferma il teorema CAP

Il teorema afferma che è possibile ottimizzare al massimo due delle tre caratteristiche appena illustrate. Non si possono progettare dei sistemi distribuiti che abbiano consistenza, disponibilità e tolleranza al partizionamento contemporaneamente perchè sarebbe teoricamente impossibile.

Infatti, i progettisti devono scegliere quale delle tre caratteristiche sacrificare. Al più si possono soddisfare due di queste proprietà contemporaneamente.

Di conseguenza, la fusione di più computer indipendenti in un unico sistema si può suddividere generalmente in tre categorie:

  • Coppia CP (coerenza e tolleranza alle partizioni). Il caso di applicazioni bancarie, che devono addebitare o trasferire in modo affidabile somme di denaro sui conti, infatti si orientano verso la coerenza e la sicurezza alle partizioni per escludere errori contabili, anche in caso di traffico dati poco stabile;
  • Coppia AP (disponibilità e tolleranza alle partizioni). È il caso della gestione di basi di dati basati sul modello di database relazionale;
  • Coppia CA (coerenza e disponibilità). Ne è un esempio il DNS, infatti il sistema è quasi sempre disponibile. Nel DNS non è fornita coerenza: in caso di modifica di una voce del DNS, possono passare dei giorni prima di riportare questa modifica nell’intera gerarchia del sistema e renderla visibile a tutti i client.

0 commenti

Lascia un commento

Segnaposto per l'avatar