Prelaurea Test
-
Upload
guest97f0c9 -
Category
Business
-
view
179 -
download
0
Transcript of Prelaurea Test
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 ?