Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
vuoi
o PayPal
tutte le volte che vuoi
TERMINALE-HOST
assegnati ad una sola macchina: (Mainframe); l’intero applicativo è assegnato ad
un unico nodo (Host), i restanti nodi non sono evoluti dal punto di vista delle risorse ma richiedono
solo l’esecuzione di particolari funzioni (Terminali Stupidi). Si tratta semplicemente del già citato
sistema centralizzato. PRO: gestione più semplice e performance e affidabilità elevate; CONTRO:
scalabilità solo verticale (scale up) e vendor-lock-in problem (vendor-lock-in= rapporto di dipendenza
che si instaura tra clienti e fornitori tale che il cliente non può acquistare stessi beni da un differente
fornitore senza sostenere elevati costi).
TWO-TIERED APPLICATIONS: i layer sono divisi tra la stazione di lavoro dell’utente e la macchina
server che ospita i dati (ho 6 configurazioni possibili). Sulla stazione di lavoro (tipicamente un PC) è
realizzata la logica di presentazione e sulla macchina server quella di accesso ai dati; ci sono diverse
configurazioni perché diverse sono le scelte di allocazione della logica applicativa e di parte degli
altri due layer, questo perché anche i terminali acquistano intelligenza quindi il carico di lavoro si
CLIENT-SERVER:
può suddividere tra host e terminali. Il paradigma di base è il questa configurazione,
risalente agli anni ’80, si basa su una macchina, detta appunto server, che carica a bordo i programmi
applicativi ed è in grado di eseguire in parallelo varie applicazioni richieste dagli utenti. Il Client è un
componente tramite cui l’utente si interfaccia al sistema (un pc o un browser) che richiede
l’esecuzione di un programma sul server; la caratteristica più importante è che lo stesso programma
fisicamente risiedente su un server può essere lanciato da vari client con dati diversi. Client e Server
possono risiedere su macchine diverse ed essere lontani (esecuzione remota) ma collegate in rete. Le
6 diverse configurazioni sono possibili in base alle modalità di allocazione dei tre laser applicativi:
comportano livelli diversi si flessibilità e facilità di modifica.
Present. distribuita- Pres. remota- App distr.- Gest. dati remota- App e dati distr.- Gest. dati distr.
Thin Client (1 e 2): a livello utente resta relegata la funzione di presentazione alleggerendo le
funzionalità della stazione utente.
Fat Client (3,4,5,6): a livello di utente si appoggia la logica applicativa e quella di accesso ai dati.
PRO: scalabilità sia orizzontale che verticale e maggiore flessibilità; CONTRO: gestione sempre più
6
complessa all’aumentare dei nodi, carico di lavoro oneroso per la parte server, difficoltà di
integrazione.
THREE-TIERED APPLICATIONS: i tre livelli applicativi sono divisi tra altrettante macchine dedicate
ovvero una stazione di lavoro utente, un server intermedio (middle tier) e un server di gestione dei
dati. In questo caso ci sono 13 configurazioni possibili (5 fat client e 8 thin client); considerando che
ho tre tier, le situazioni di thin client contengono tutte le configurazioni con solo la presentazione
nella stazione utente, quelle di fat client invece prevedono le realtà in cui le unità aziendali che
cooperano sono interne (sistema basato su rete locale o Internet). Le configurazioni che utilizzano tre
tier sono sicure perché i processi per la gestione dei dati e i processi utente non condividono in alcun
modo l’ambiente di esecuzione. PRO: scalabilità sia orizzontale che verticale, maggiore flessibilità,
migliore distribuzione del carico di lavoro, totale indipendenza tra i livelli; CONTRO: gestione
dell’architettura molto complessa, spreco di risorse. Il server intermedio è importantissimo perché
riesce a centralizzare la logica applicativa in modo tale che sia sufficiente garantire l’efficienza di
esso per avere un’adeguata condivisione tra i diversi client; il middle tier è dimensionato in modo tale
da garantire un predeterminato livello di prestazioni per un certo numero di utenti
contemporaneamente attivi; esso riduce il carico al server dedicato alla gestione dei dati mantenendo
connessioni permanenti con il DBMS in modo tale che il numero di sessioni aperte tra questo e il
DBMS sia inferiore al numero di connessioni aperte tra il client e il tier intermedio.
N-TIERED APPLICATIONS: nelle implementazioni reali si adottano spesso soluzioni con più di tre
tier introducendo per esempio tier legati esclusivamente alla comunicazione come i server gateway
che, quando più sorgenti sono integrate e vengono consultate in tempo reale, vengono inseriti tra di
esse e l’application server e che hanno il compito di fornire un accesso trasparente ai DBMS della
rete traducendo le chiamate dell’app. server nella struttura della sorgente dei dati remota: ciò facilita
la comunicazione ed evita che lo sviluppatore debba conoscere i dettagli delle basi di dati remote e
delle relative modalità o linguaggi di accesso.
FRONT-END __ APP. SERVER __ GATEWAY (traduce chiamate) __ SORGENTI DI DATI—>FOUR-TIER
SERVER FARM: nei moderni sistemi i tier fisici possono essere realizzati anche come server farm,
ovvero come un insieme di elaboratori che condividono il carico elaborativo, le applicazioni e, a
seconda della configurazione, i dati. Nella server farm la scalabilità orizzontale di ognuno dei tier è
realizzata attraverso repliche e/o ripartizioni dei layer. Letteralmente “Fattoria di server” una server
farm è costituita da una serie di server collocati in un unico ambiente in modo da poterne
centralizzare la gestione, la manutenzione, la sicurezza; attraverso architettura distribuita si
gestiscono carichi di lavoro pesanti o critici. Grazie ai sistemi di Load Balancing (bilanciamento di
carico) si riesce a distribuire il carico di elaborazione di uno specifico servizio tra più server
aumentando in questo modo la scalabilità. PRO: maggiore flessibilità, tolleranza ai guasti e costi di
scalabilità ridotti; CONTRO: maggiori costi di gestione e difficoltà nel dimensionamento. La
realizzazione delle server farm si basa su due princìpi progettuali:
CLONING: operazione fondamentale che permette di clonare server nei quali nodi sono installate le
medesime applicazioni e gli stessi dati. L’operazione si svolge in tre passaggi:
1) Creazione di un server con le medesime configurazioni del server di base.
2) Creazione di un nuovo disco di memorizzazione che è una copia uguale del disco di
memorizzazione di base.
3) Inserimento del disco nel nuovo server.
Il cloning è uno strumento utile per la scalabilità orizzontale perché mi permette di aggiungere
facilmente più server dietro il load balancer. E’ anche utile appunto perché mi permette di avere un
server uguale ad uno che ho già senza perdere tempo a configurarlo. Ogni clone implementa lo
stesso insieme di funzionalità mentre un load balancer instrada ai vari cloni le richieste. RACS
(Reliable Array of Cloned Service)= insieme di cloni dedicati allo svolgimento di un particolare
servizio. Ci sono due configurazioni possibili:
a) SHARED NOTHING: ogni clone ha una copia di tutte le applicazioni e un proprio disco su cui
sono memorizzati i dati delle applicazioni installate sul clone. E’ necessario effettuare un
aggiornamento per ogni clone; le prestazioni sono migliori per applicazioni “solo lettura” ma
diventano scadenti con configurazione problematica per i servizi write-intensive.
b) SHARED DISK: ogni clone ha una copia di tutte le applicazioni ma i dati risiedono su un’unica
macchina condivisa da tutti i cloni; l’aggiornamento però, anche in questo caso, va fatto ad ogni
7
clone; si tratta di una configurazione rischiosa perché l’accesso ai dati potrebbe diventare il collo di
bottiglia che vede però una gestione più semplice nei servizi write-intensive.
PARTITIONING: si prendono le diverse applicazioni e si distribuiscono tra le diverse macchine. I dati
sono distribuiti sui nodi di competenza perché ogni nodo svolge una funzione specializzata. Il
partizionamento rimane trasparente ai client, il load balancer si occupa sempre di instradare le
richieste in maniera opportuna. Attenzione: la disponibilità non per forza migliora perché i dati sono
su un singolo server e, in caso di guasto, la parte di servizio da esso gestita non è più disponibile.
RAPS (Reliable Array of Partitioned Service) garantisce scalabilità, maggiore disponibilità di servizio e
risolve il problema di indisponibilità dovuto al fallimento di un nodo attraverso il cloning (perché si
clonano i singoli server che costituiscono la partizione).
SERVER CONSOLIDATION: si tratta della ricentralizzazione delle applicazioni dei sistemi distribuiti
su un numero inferiore di macchine fisiche con l’obiettivo di ridurre i costi dell’impianto informatico.
E’ un’attività che deve essere fatta perché nei sistemi distribuiti i server sono utilizzati con una media
del 5-10% delle loro potenzialità e in questo modo si hanno sprechi economici e di risorse. Il
problema del consolidamento risiede nel fatto che, la coesistenza nello stesso ambiente di
applicazioni diverse o che potrebbero avere requisiti contrastanti, porta al malfunzionamento di tutte
le applicazioni se una in particolare non funziona, e ciò non è accettabile. Per questo è necessario
garantire l’ISOLAMENTO DELLE APPLICAZIONI e, per fare ciò, si usa la VIRTUALIZZAZIONE. Per
risparmiare sui costi è possibile far eseguire da una stessa macchina due applicazioni per cui il picco
di carico di una coincide con le valli dell’altra: questo appunto per utilizzare di più un server non
facendo decadere le prestazioni e diminuendo i costi di gestione (app di fantacalcio: il picco c’è in
corrispondenza di venerdì, sabato e domenica, negli altri giorni posso mettere un software che ha
valli nei giorni di picco del fantacalcio e picchi nei giorni di valle del fanta).
VIRTUALIZZAZIONE=>ISOLAMENTO: in ambienti che condividono la stessa macchina fisica
MACHINE:
permette l’isolamento delle applicazioni. VM=VIRTUAL macchina virtuale in cui risiede
l’applicazione a cui essa è totalmente dedicata. In realtà su una macchina fisica risiedono diverse
macchine virtuali; VM è semplicemente un file contenente tutte le informazioni su quanta CPU o
RAM (per esempio) devo andare a beccare quando viene aperto. Essendo un file può facilmente
migrare ed essere raggiunto da tutti; ci sono due tipologie di migrazione:
A FREDDO: spengo VM, ottengo file, sposto file su un altro sistema, faccio ripartire.
A CALDO: prendo VM mentre sta funzionando e la sposto; in questo caso spostare significa lasciare
delle risorse e richiederne altre dall’altra parte (si tratta di u