RETI DI CALCOLATORI

PROGETTO E RELAZIONE
(Muzzi Matteo matr 2148 52790)

Introduzione

Il progetto in questione si propone di realizzare un software per un sistema di rete che si propone la gestione di un'attività bancaria , in particolare la gestione di sportelli bancomat. In particolare il mio sistema software si propone di realizzare l'interconnessione fra I vari server delle mie filiali e gli eventuali sportelli bancari o clienti che si collegano da terminale.

Obbiettivi e specifiche di progetto.

Gli obbiettivi fondamentali del mio progetto sono quelli di realizzare un sistema:

TOLLERANZA AI GUASTI: il sistema deve fornire un servizio in ogni possibile configurazione di guasto , ipotizzato però singolo.

EFFICIENZA DEL SISTEMA: intesa non tanto come effiecienza realizzativa in fatto di codice quanto come efficienza del progetto.

SCALABILITA' : il sistema è pensato per funzionare in un'ambito nazionale e quindi un problema intrinsecamente vasto , l'approccio al problema però vuole rendere la soluzione il più scalabile possibile.

TRASPARENZA COMUNICATIVA: il mio sistema deve realizzare I meccanismi comunicativi in modo del tutto trasparente all'utilizzatore .

DINAMICO , PREVEDENDO MOBILITA': il mio sistema deve intrinsecamente essere in grado di riconoscere eventali migrazioni sulla rete delle mie risorse e adeguarsi di conseguenza .

ETEROGENEITA' : il mio sistema deve poter essere accessibile da parte di un qualunque tipo di terminale.

Qesti sono I requisiti di base che il progetto si propone. La realizzabilità o meno di tali requisiti in sede di implementazione costituirà una significativa retroazione sul progetto stesso , probabilmente introducendo eventuali semplificazioni ed ipotesi di impiego semplificative.

SCHEMA DI REALIZZAZIONE DEL PROGETTO.

Lo schema fondamentale di realizzazione del mio progetto prova in modo ancora molto astratto a rispondere alle esigenze prodotte durante la fase di specifica del problema stesso.

TOLLERANZA AI GUASTI: il problema della tolleranza ai guasti viene risolto dalla replicazione delle risorse in gioco. In particolare per aumentare efficienza e scalabilità del mio progetto la replicazione è fatta attraverso l'utilizzo di copie attive della mia risorsa. In particolare per l'ipotesi fatta all'inizio di gusto singolo le copie di ogni risorsa previste saranno due. Ovviamente l'ipotesi di gusto singolo in ambito di rete soprattutto è quanto meno limitativa ma di certo non sarebbe difficile poi estendere il mio progetto per realizzare 3 4 5 … n copie della mia risorsa.

EFFICIENZA DEL SISTEMA e SCALABILITA' : come abbiamo spiegato prima il concetto di efficienza è trattato sotto il profilo dell'efficienza del mio progetto e non tanto dell'implementazione software che non intende realizzare un prodotto finito. In particolare quindi il problema dell'efficienza nel nostro progetto viene risolta utilizzando fondamentalmente 3 metodi:

Principio di località : cioè l'azione perchè sia efficiente deve riguardare operazioni quanto più possibili limitate ad una determinata località.

Principio di minima intrusione e comunicazione: la comunicazione deve essere limitata quanto più possibile.

Principio di organizzazione gerarchica del mio sistema.

TRASPARENZA COMUNICATIVA : è ottenuta attraverso l'utilizzo di un'opportuno protocollo di comunicazione tra I vari componenti.

ETEROGENEITA' :scelta di JAVA come linguaggio di implementazione.

Nel modello di risoluzione proposto emerge subito l'organizzazione a 3 gerarchie ,DNS che svolge un compito a livello nazionale , operation server che fungono da server a livello di città e le filiali che costituiscono le singole banche a livello di città .

Le gerarchie di livello inferiore in particolare non conoscono nulla di quelle di livello superiore . Quelle di livello superiore conoscono invece nomi simbolici ed indirizzi fisici di quelli immediatamente al disotto.

La comunicazione abbiamo detto deve essere il più limitata possibile , in particolare può avvenire tra gemelli parigrado oppure soltanto verso l'alto. I gemelli parigrado non sono altro che delle filiali che conservano una copia di lavoro di un'altra , se una qualunque centrale cade allora le transazioni risultano ugualmente possibili perchè il DATA-BASE relativo al cliente è ancora disponibile .

A questo punto vediamo la realizzazione di ogni singolo componente specificando anche il compito.

DNS

Il DNS rappresenta un server a livello teoricamente nazionale o globale. Per tale motivo il DNS non può conoscere il nome di tutti I nodi filiale , sarebbe ovviamente troppo oneroso , ipotizziamo allora che il server abbia la completa conoscenza soltanto dei nodi della gerarchia immediatamente al disotto.

In particolare il mio DNS fornisce a fronte di una richiesta da parte di un cliente il server operator geograficamente più vicino , e meno occupato.

Si deve anche incaricare di registrare nuovi operator server e di schedarli.

Per realizzare un servizio tollerante ai guasti singoli abbiamo replicato la risorsa server attraverso due DNS ddel tutto indipendenti quindi eseguibili su due nodi diversi che costituiscono copie attive , quindi realizzando anche una sorta di suddivisione del carico di lavoro complessivo.

Rappresentano I processi thread che operano su ognuno dei due server:

In particolare avrò

Un thread adibito alla comunicazione tra I due DNS per aggiornare mutuamente le tabelle
Un thread di comunicazione per I clienti
Un thread per gestire la comunicazione con gli eventuali operation server

Il mio nodo DNS deve allora contenere le seguenti strutture dati:

Un TABELLA di corrispondenze operator località geografica indirizzo fisico gemmello

Nome logico

Località di copertura

Indirizzo fisico

Nome del gemello

Una TABELLA identica a questa per il BACKUP della tabella dell'altro pari
Una tabella eventualmente per creare un operatore gemello virtuale.Tale possibilità forse non sarà prevista realizzando due corrispondenze verso un solo nodo.

Il DNS deve mettere a disposizione le seguenti funzioni di servizio:

Gestione del CRASH del gemello: tale funzione serve per rendere possibile anche nel caso di una crash del nodo S2 di continuare l'attività sfruttando la tabella di backup di S1. Quindi le chiamate dei client verranno deviate su S1 che si incaricherà di indirizzarle correttamente.

Gestione delle richieste del client: è l'operazione principale svolta dal server , a fronte di una richiesta del mio server ne individua la zona di provenienza e la indirizza opportunamente.

Gestione della tabella del gemello con eventuale aggiornamento dinamico: serve per mantenere consistente la tabella di backup del mio S1 in modo che in caso di crash possa sostituire correttamente S2.

Gestione di richieste di inserimento o rilascio di un nodo OPERATOR. :è la funzione che consente ai nodi di spostarsi in maniera dinamica nella rete. Tale operazione richiede un protocollo oneroso di ricoordinamento e quindi ipotizzabile essendo poi nodi importanti che il server si sposti poco.

Gestione gemello di operator: ogni OPERATOR per come è stato concepito il mio sistema deve possedere un gemello. In caso I nodi operator risultino in numero dispari tale funzione si incarica di mantere un virtual operator twins in memoria , in pratica una tabella di copia dell'ultimo operator.

OPERATOR NODE

Il nodo operator corrisponde praticamente al nodo geografico che gestisce il traffico sulle singole filiali di banca , tale nodo si incarica di indirizzare ogni richiesta fatta dal client sul proprio server di filiale. Nel caso il server di filiale risulti o particolarmente intasato oppure in crash si incarica di redirigere la richiesta del client sul nodo .

STRUTTURE DATI:

ogni nodo operatore contiene due strutture dati al proprio interno , due tabelle di corrispondenze relative alle filiali della propria città ed a quelle della filiale associata.

Ognuno deve poter fornire I seguenti servizi:

Gestione dell'inserimento di una nuova filiale: ogni volta che si inserisce una nuova filiale il sistema deve generare una nuova riga nella tabella ed eventualmente inserirvi una nuova voce relativa alla nuova filiale. Deve anche attraverso n'opportuno algoritmo decidere quale filiale sarà la gemella , ed in caso di abbandono di una dire a chi sarà gemellata quella futura.
Gestione del CRASH di uno dei nodi gemelli :in caso del crash di un componente della coppia il server deve incaricarsi di redirigere il traffico dei vari clienti.
Gestione della richiesta dei singoli clienti: deve guardando la località del singolo cliente determinare a quale filiale è affiliato e passarvi l'indirizzo per il collegamento.

Filiale

Il nodo filiale ha una struttura molto simile a quella del nodo operator , in particolare però esso deve gestire e creare il concetto di TRANSAZIONE. In particolare FILIALE ha fondamentalmente due strutture dati del tutto simili, queste strutture sono tabelle che mantengono memoria delle transazioni e dei clienti registrati.

Le operazioni alle quali deve rispondere la mia struttura dati è

Registrazione di un nuovo cliente
Risposta alle richieste di transazione effettuate dai clienti
Generazione di una o due tabelle di backup , gestione della comunicazione con filiale.
Gestione del reinserimento di una filiale in crash
Gestione del traffico e generazione dei messaggi di errore.

PROTOCOLLI.

I protocolli pensati per la comunicazione risultano pensati per fornire tolleranza ai guasti da parte del servizio che deve sempre risultare accessibile ad ogni cliente.

In particolare tale protocolli risultano troppo onerosi in particolare nella fase di recupero da guasto , causando il trasferimento di interi db. Si può pensare però di risolvere in maniera del tutto locale questi problemi considerando di creare in locale il concetto di memoria stabile , introducendo ad esempio una sere di dischi RAID. Quindi a fronte di un gusto il server si deve soltanto incaricare di trsferire le MODIFICHE.

Protocollo numero 1 : comunicazione normale tra OPERSERVER e DNS per gestire un nuovo inserimento .

Lo inserisce nella tabella,

Ne calcola il gemello invia I dati all'altro DNS

L'operator server invia una

Richiesta di inserimento

PROT n° 4

Invia ACK a OPSERVER

Protocollo numero 2 : Protocollo di richiesta speciale effettuata da OPERATORSERVER a DNS2
Il protocollo di richiesta speciale viene effettuato dal server al DNS2 a fronte di una non risposta da parte del server DNS1 cioè guasto probabile.

SPECIAL REQ SPECIAL REQ

Richiesta con diritto di precedenza , mi sincero se è ancora vivo

Protocollo numero 3: protocollo destinato al controllo del server dns .
Tale protocollo è inserito per controllare se l'informazione ricevuta dal OPERATOR SERVER che il corrispettivo server è caduto è vera oppure il DNS non ha risposto perchè era intasato. Quindi si invia un messaggio su di un canale prioritario per la verifica. A fronte di questo se non si riceve alcun messaggio di risposta si procede considerandolo OUT altrimenti si riceve ugualmente la modifica da parte di operat server ma la si invia al DNS1 come modifica.

Protocollo numero 4: coordinamento tra I due DNS per mantenere coerenti le due tabelle a fronte di modifiche.

E' il protocollo di normale amministrazione , a fronte di una modifica nella tabella del DNS viene recapitato un messaggio di richiesta al server gemello e vengono registrate le modifiche , solo allora viene dato consenso alla richiesta rispetto al OPERATOR SERVER.

Protocollo numero 5: protocollo di interrogazione da parte del CLIENTE del DNS.
Il cliente interroga il DNS e riceve il nome del proprio OPERATOR SERVER, tale operazione viene effettuata soltanto durante la prima connessione o a fronte di un CRASH del nodo , in caso contrario il CLIENTE stesso si incarica di fare CACHING dell'indirizzo dell' O.S e non ha più bisogno di richiederlo.

Protocollo numero 5 bis: il cliente si accorge che l'operator server assegnatoli non risponde.

Il cliente interpreta una non risposta del O.S come un fallimento e quindi riinterroga il nodo DNS per avere il nome del server GEMELLO . Il DNS prende atto che il server è DOWN e ridirige il traffico sul gemello comunicando al gemello che il suo pari è in CRASH. Il gemello a fronte di ciò registra le chiamate come speciali. Quando recuperato il sever O.S manda un messaggio al mio DNS che lo recepisce e lo riscrive come funzionante.Il server DNS in realtà può anche ignorare la notizia e proseguire normalmente.
Protocollo numero 6:per il ripristino del DNS a fronte di un CRASH.

Il server che ha avuto un problema , una volta che lo ha risolto invia una richiesta di reinserimento al server DNS gemello. Tale server a fronte di questa richiesta blocca ogni richiesta di trasferimento o aggiunta da parte degli OPERATOR SERVER, rispondendo soltanto alle richieste dei CLIENT. A questo punto apre una connessione TCP/IP ed inizia il trasferimento delle informazioni relative alle modifiche apportate alla tabella del DNS1 e poi a quelle relative alla propria dall'ultimo CHECK in avanti , quindi terminato invia un EOF ed attende la risposta da parte del DNS1 e chiude la connessione.

In realtà la connessione con gli OPERATOR SERVER non viene rifiutata , la mancata risposta sarebbe interpretata dagli OPERATOR SERVER come un CRASH del nodo , ma viene inviato un messaggio di negazione del servizio, tale messaggio arriva ai OPERATOR SERVER che a fronte di ciò non fa altro che mettersi in stand-by e riprovare dopo un certo intervallo di tempo più o meno lungo. Altrimenti , soluzione secondaria potrebbe essere quella di mantenere traccia da parte del DNS delle modifiche rifiutate ed una volta terminato effettuare un MULTICAST su tali O.S.

Protocollo numero 7: coordinamento tra I due OPERATOR SERVER gemelli.

Tale protocollo risulta in via pratica del tutto identico a quello che effettua il coordinamento tra I due DNS .

Protocollo numero 8: richiesta di un nodo filiale da parte di un cliente
Il protocollo è realizzato attraverso una connessione TCP/IP . Il cliente si collega alla filiale ed effettua le possibili transazioni . Ogni transazione di tipo scrittura è organizzata come una REQUEST ZONE ossia il cliente richiede la transazione , il server verifica la possibilità , aggiorna la tabella della FILIALE gemella , aggiorna la sua e quindi conferma la transazione al CLIENT , nel caso che una qualunque di queste 3 operazioni fallisca il server siincarica di annullare tutte le precedenti transazioni.

Protocollo 9 : comunicazione tra due filiali per aggiornare le tabelle.
Tale comunicazione avviene tramite un canale TCP/IP , le transazioni devono essere sicuramente ricevute ed ordinate , in particolare prima deve essere fatto l'aggiornamento sulla tabella di BACKUP quindi l'aggiornamento sulla tabella di uso quindi solo dopo tutto questo deve essere confermata la transazione.

Protocollo numero 10: recupero di un guasto tra le filiali gemelle.
Qui il problema fondamentale è rappresentato dal fatto che la filiale che si reinserisce non può aggiornare la sua tabella di BACKUP e quella originale se la filiale con cui comunica continua a servire clienti , allora quello che viene fatto è continuare a rispondere ai clienti ma impedire loro ogni tipo di modifica fino al ripristino completo della tabella. Una volta completata tale operazione viene riattivata la FILIALE e le operazioni possono continuare in modo normale.

Vediamo adesso un breve quadro riassuntivo sulle possibili comunicazioni tra I vari componenti ed I protocolli utilizzati per realizzarli.