Anteprima
Vedrai una selezione di 6 pagine su 25
Riassunto tutte le lezioni di Sistemi informativi, prof. Plebani Pag. 1 Riassunto tutte le lezioni di Sistemi informativi, prof. Plebani Pag. 2
Anteprima di 6 pagg. su 25.
Scarica il documento per vederlo tutto.
Riassunto tutte le lezioni di Sistemi informativi, prof. Plebani Pag. 6
Anteprima di 6 pagg. su 25.
Scarica il documento per vederlo tutto.
Riassunto tutte le lezioni di Sistemi informativi, prof. Plebani Pag. 11
Anteprima di 6 pagg. su 25.
Scarica il documento per vederlo tutto.
Riassunto tutte le lezioni di Sistemi informativi, prof. Plebani Pag. 16
Anteprima di 6 pagg. su 25.
Scarica il documento per vederlo tutto.
Riassunto tutte le lezioni di Sistemi informativi, prof. Plebani Pag. 21
1 su 25
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

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

Dettagli
Publisher
A.A. 2016-2017
25 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher aute95 di informazioni apprese con la frequenza delle lezioni di Sistemi informativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Politecnico di Milano o del prof Plebani Pierluigi.