Prova di prelaurea (fittizia)

❚ SAN (Storage Area Network)

❙ Disco separato dal nodo file server (o NAS)

❙ Collegamento con una network dedicata

SAN

SCSI

ProcessoFile Server

Comandia livello di disk block

(NON di file)

ProcessoFile Server

Comandia livello di disk block

(NON di file)

Applicazioni

...

❚ Traffico applicativo(interno alle applicazioni)

Che significa ?Cosa si comunicano le applicazioni ?

Cluster (I)Interconnect

... ...

Cluster (I)

Interconnect

SAN / NAS

...

Network

RitagliFailures

Failures“Failure”:

❚ Il componente cessa di funzionare

❚ I componenti che lo utilizzano rilevano che ha cessato di funzionare

Possono verificarsi failure di:

❚ Processo

❚ Nodo

❚ Altro componente software

❚ Altro componente hardware

Quali sono gli effetti ?

Gestione FailuresApproccio generale:

❚ Failure masking: Il sistema nasconde la failure del componente

❚ Transient failure

❙ Riprovando, la failure non si verifica

❙ Per avere failure masking basta riprovare(facendo attenzione a non eseguire l’operazione più volte)

❚ Permanent failure

❙ Anche riprovando, la failure permane

❙ Per avere failure masking è necessaria (ma non sufficiente)ridondanza del componente

Transient Failures:In Pratica

❚ Si verificano solo:

❙ A livello hardware

❙ Nel sistema di comunicazione (livello fisico)

❚ Devono essere considerate solo dai progettisti “di basso livello”

❚ Ad alto livello sono:

❙ Assenti (failure masking)

❙ Presentate come permanent failure(no retry)

❚ Consideriamo solo le permanent failures

Terminologia

❚ Highly available: Failure masking di nodi e processi

❙ Di solito, failure di componenti hw/sw sono trasformate in failure di nodi/processi

❙ Può essere “no single point of failure” o meno(di solito non è facile capirlo)

❚ Fault-tolerant :

❙ Highly availableoppure❙ Riferito ad un singolo nodo, failure masking di componenti hw /

sw

❙ La “terminologia commerciale” non è molto uniforme / rigorosa

PertantoApplicativo Server:

❚ Solo operazioni idempotenti

❚ Operazioni non idempotenti con “duplicati non critici”

❚ Il failure recovery si può fare banalmente,re-inviando le operazioni in-doubt

Applicativo Server:

❚ Operazioni non idempotenti con “duplicati critici”

❚ Il failure recovery è complicato: non si possono re-inviare le operazioni in-doubt

Cosa può essere accadutoServer:

❚ Non ha ricevuto Request

❚ Crash durante esecuzione, LongTermState consistente “prima”

❚ Crash durante esecuzione, LongTermState inconsistente

❚ Crash durante esecuzione, LongTermState consistente “dopo”

❚ Invia Response, Crash del server, Response persa

❚ Nella prossima connessione con il server,la request deve essere reinviata o no ?

❚ Problema fondamentale

❚ Deve essere tenuto presente in ogni applicativo

❚ Indipendentemente dalla presenza di SessionState(si verifica sia con servizi stateless che con servizi stateful)

Unrecoverable error:Come gestirlo ?

❚ Approccio teorico (quello che si dovrebbe fare):

❚ Analizza la sessione interrotta e determina:

❚ 1) Operazioni già eseguite

❚ 2) Operazioni già iniziate il cui esito non è noto

❚ 3) Operazioni non ancora iniziate

❚ Nella nuova sessione:

❚ Omette 1

❚ Esegue 3

❚ Cerca di capire cosa è accaduto per ogni operazione in 2

❚ Se l’operazione non è stata eseguita, la esegue

Importantissimo

2) Operazioni già iniziate il cui esito non è noto

❚ Possono esistere in ogni applicativo

❚ Client invia request

❚ La connessione cade prima di ricevere response

❚ Nel failure recovery di ogni applicativo occorre implementare la parte complicata

Cerca di capire cosa è accaduto per ogni operazione in 2

Se l’operazione non è stata eseguita, la esegue

Casi complicati

❚ Operazioni del server

❚ Bonifico

❚ Acquisto

❚ Notifica di organo umano disponibile per donazione

❚ ...

❚ Il protocollo è ininfluente(HTTP con scrittura, Java RMI, CORBA, …)

❚ Non si può ripartire come se nulla fosse !!!

Casi complicati:Come si gestiscono ?

❚ Dipende...

❚ Non esiste una soluzione generale

❚ Ogni applicativo necessita di una soluzione specifica

Ric❚ Approccio teorico (quello che si dovrebbe fare):

❚ Analizza la sessione interrotta e determina:

❚ 1) Operazioni già eseguite

❚ 2) Operazioni già iniziate il cui esito non è noto

❚ 3) Operazioni non ancora iniziate

❚ Nella nuova sessione:

❚ Omette 1

❚ Esegue 3

❚ Cerca di capire cosa è accaduto per ogni operazione in 2

❚ Se l’operazione non è stata eseguita, la esegue

Esempio❚ POP: Prelievo di 18 email

❚ SMTP: Invio di 4 email

❚ In generale:

❚ Analizza la sessione interrotta e determina:

❚ 1) Operazioni già eseguite

❚ 2) Operazioni già iniziate il cui esito non è noto

❚ 3) Operazioni non ancora iniziate

❚ Nella nuova sessione:

❚ Omette 1

❚ Esegue 3

❚ Cerca di capire cosa è accaduto per ogni operazione in 2

❚ Se necessario, esegue

Unrecoverable error:Come gestirlo ?

❚ Le azioni del Client a questo punto dipendono dall’applicazione

❚ Tentativo

❚ Caso banale

❚ Riparte dall’inizio come se nulla fossesuccessive aldeve riaprire connessione verso lo stesso indirizzo IP

❚ Servizio stateless

❚ Continua come se nulla fosse

❚ Servizio stateful, Sessione Connessione

❚ Sa che la sessione è stata interrotta

❚ Unrecoverable error

❚ Servizio stateful, Sessione Connessione

❚ Si sente dire che la sessione non esiste più !

❚ Unrecoverable error

In pratica...

POP, SMTP, FTP

HTTP, SSL, Kerberos

CORBA, DCOM, JavaRMI

Stateless

NFS, DNS (su TCP), HTTP

Stateful

Stateful

Non si accorge di nulla

Client riparte dall’inizio(omettendo le operazioni già eseguite)

Unrecoverable error

Osservazione“Failure”:❚ Il componente cessa di funzionare❚ I componenti che lo utilizzano rilevano che ha cessato di

funzionare

❚ Cosa accade se il componente continua a funzionare mafornisce fischi per fiaschi ?(byzantine failure)

❚ Ignoriamo questo tipo di problemi

❚ Richiedono tecniche e sistemi completamente diversi

Osservazione

❚ Highly available

❚ Alta efficienza

❚ Requisiti ovviamente in conflitto

❚ Highly available richiede ridondanza

❚ Ridondanza significa “inutilizzato in condizioni normali”

Osservazione“Failure”:❚ Il componente cessa di funzionare❚ I componenti che lo utilizzano rilevano che ha cessato di

funzionare

❚ Cosa accade se il componente continua a funzionare mafornisce fischi per fiaschi ?(byzantine failure)

❚ Ignoriamo questo tipo di problemi

❚ Richiedono tecniche e sistemi completamente diversi

Regola generaleUn HPC ClusterE’ progettato per avere alte prestazioniNon è progettato persono “Failure”:

❚ Il componente cessa di funzionare

❚ Gli altri componenti rilevano che ha cessato di funzionare

Possono verificarsi failure di:

❚ Processo

❚ Nodo

❚ Altro componente hardware

Quali sono gli effetti ?