Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo

Transcript

1 La progettazione dell architettura si concentra sulla scelta dell hardware, dell infrastruttura di rete, e dei componenti software che andranno a costituire il sistema. Gli obbiettivi tecnologici che il progettista deve porsi sono: Prestazioni: l applicazione deve sostenere il carico di lavoro previsto espresso in numero di utenti simultanei e il numero di richieste di pagine servite nell unità di tempo; Scalabilità: l architettura deve essere estendibile in modo che se il carico di lavoro cresce è possibile aggiungere maggior potenza di calcolo mantenendo stabili le prestazioni; Disponibilità: l applicazione deve funzionare in modo continuativo e i guasti non devono influenzare il servizio fornito all utente; Mantenimento dello stato: lo stato dell interazione dell utente deve essere preservato anche quando l applicazione è distribuita su diverse macchine; Sicurezza: le informazioni memorizzate nello strato dei dati e scambiate tra l applicazione ed i suoi utenti devono essere protette, inoltre gli utenti devono accedere alle sole informazioni per cui hanno diritto. La progettazione di una architettura non si pone solo degli obbiettivi ma deve anche rispettare alcuni vincoli: Costi: ogni risorsa ha un costo, il budget può limitare la scelta delle risorse hardware e software; Complessità: ci sono configurazioni che possono essere realizzate e mantenute più semplicemente di altre, la mancanza o il costo elevato di personale può vincolare il progetto dell architettura; Standard e infrastrutture aziendali: l applicazione deve essere installata all interno della infrastruttura dell azienda e ciò può limitare nelle scelte. La scelta del luogo dove verrà installata l architettura è una delle scelte più importanti, gli scenari di installazione attualmente possibili sono: Installazione interna: l architettura si trova all interno dell azienda ed è gestita dall azienda stessa; Housing: l architettura è gestita dall azienda ma è installata presso un provider; Hosting: l architettura è gestita ed installata presso un provider. Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo Host 1 Web Execution engine Database Questo tipo di configurazione è la più semplice. In questo tipo di configurazione i componenti fondamentali sono: Web ; Motore esecuzione degli script; Base di dati.

2 La caratteristica fondamentale di questa configurazione è che i tre componenti sono installati tutti sulla stessa macchina. L host è connesso alla rete aziendale ed è connesso ad internet per mezzo del router/. La configurazione può essere valutata secondo gli obbiettivi prima descritti: Prestazioni: il traffico è limitato alla configurazione dell host in termini di velocità della cpu, memoria e latenza di accesso al disco fisso; questo tipo di configurazione genera colli di bottiglia dovuti alla necessità di memoria richiesta da motore degli script e base di dati; Scalabilità: per espandere il sistema si richiede un incremento di potenza oppure un hardware più complesso, la scalabilità massima è così limitata dall architettura hardware del ; Disponibilità: se si verifica un singolo guasto su un componente qualsiasi il sistema intero si blocca; la tolleranza ad i guasti può essere migliorata aggiungendo risorse hardware ridondanti; Mantenimento dello stato: siccome si ha una sola macchina i dati degli utenti sono a disposizione subito; Sicurezza: da questo lato questo tipo di architettura è molto debole in quanto una volta oltrepassato il si hanno a disposizione tutte le informazioni; Costo: il costo è basso fino a che non viene richiesto un parallelismo massiccio; Complessità: questa è la configurazione più semplice in quanto si risparmia molto per la configurazione e messa in opera. Questo tipo di configurazione è indispensabile per applicazioni a bassa scala dove gli obbiettivi sono la semplicità, i costi ridotti e dove la sicurezza dei dati non è fondamentale. Separazione del di gestione della base di dati Per migliorare l architettura dobbiamo iniziare ad effettuare una separazione delle base di dati dal. Host 1 Host 2 Web + Execution engine Database Demilitarized zone (DMZ) Questa soluzione ha degli impatti positivi: Prestazioni: la separazione fisica della base di dati e del web permette un dimensionamento più adeguato delle macchine coinvolte; Scalabilità: migliora in quanto è possibile lavorare separatamente sullo strato intermedio e sullo strato dei dati; in genere il primo collo di bottiglia risiede nello strato intermedio in quanto si ha web e motore degli script che devono lavorare sulla stessa machina; Disponibilità: la disponibilità è indebolita dal fatto che ogni componente rappresenta un singolo punto di rottura e quindi di collasso; l introduzione di risorse ridondanti può migliorare la disponibilità; Sicurezza: la sicurezza migliora notevolmente in quanto grazie al secondo si viene a creare una zona demilitarizzata dove è presente la sola zona intermedia inoltre il secondo può bloccare completamente le richieste e lasciar passare le sole richieste indirizzate alla sola base di dati.

3 È importante introdurre a questo punto il concetto di replicazione e parallelismo: questi due principi vengono introdotti per aumentare le prestazioni, la scalabilità e la disponibilità; esistono due tipi di parallelismo: Replicazione verticale: un singolo include diversi processi indipendenti e ospita molteplici processi dell applicazione; Vertical cloning Host 1: Process 1 Process 2 Process 3 Process 4 Replicazione orizzontale: interi vengono replicati. Horizontal cloning Host 1: Process Host 2: Process Host 3: Process Host 4: Process Le due soluzioni non si escludono a vicenda in quanto si posso replicare host che usano replicazione verticale. Il compromesso tra i due tipi di replicazione è da valutare in termini economici e di hardware. In genere la replicazione orizzontale è meno costosa e fornisce la massima scalabilità però comporta una maggior complessità di gestione. La replicazione porta sempre a vantaggi in termini di prestazioni, scalabilità e disponibilità: Prestazioni e scalabilità: consente il bilanciamento del carico di lavoro, il traffico in ingresso viene suddiviso tra i vari processi in maniera tale che ognuno abbia una frazione bilanciata dell intero traffico. Se il bilanciamento del carico è utilizzato assieme con una replicazione virtuale è necessario un meccanismo di clustering (gruppo di debolmente accoppiati capaci di fornire una visione unificata dei servizi offerti individualmente); Disponibilità: la replicazione permette di attuare il meccanismo di ripristino dai guasti. Se un processo o un nodo è soggetto a malfunzionamento il suo carico può essere ridistribuito agli altri processi o nodi impedendo il blocco dell applicazione. Il parallelismo si utilizza a tutti i livelli dell architettura di un applicazione web. Replicazione del web Il primo esempio di replicazione orizzontale è il seguente: Web + engine 1 Host 2 S Web + engine 2 Database DMZ Web + engine 3 In questo tipo di architettura viene replicato il web e lo script engine. In questa soluzione il router/ funge da dispatcher di rete e distribuisce le richieste ad i diversi per bilanciare il carico.

4 In caso di malfunzionamento il dispatcher utilizza gli altri permetto di mantenere in vita il servizio. Questa architettura influisce però sulla gestione dello stato dell utente qualora lo stato fosse memorizzato sotto forma di dati di sessione nell interprete degli script. La gestione dello stato in un architettura replicata richiede che venga riprodotta o simulata la relazione uno-a-uno tra il client ed il. Per preservare l integrità delle sessioni la politica di bilanciamento del carico deve garantire che le informazioni di stato siano messe a disposizione del scelto per rispondere alla richiesta. Per ottenere questo obbiettivo la tecnica che viene utilizzata maggiormente è l affinità di sessioni ovvero un associazione mantenuta da il componente che gestisce il bilanciamento del carico tra ogni sessione attiva e il che l ha creata. Questa associazione viene instaurata al fine di inviare allo stesso tutte le richieste relative ad una certa sessione. Questa tecnica è detta sticky session. Al fine di gestire questa tecnica il componente preposto al bilanciamento del carico deve essere in grado di analizzare il contenuto delle richieste in arrivo. Questa gestione dello stato non influenza solamente il bilanciamento del carico ma anche le procedure di ripristino dai guasti, infatti la sessione utente potrebbe andare persa quando si verifica un malfunzionamento del che la gestisce. Questo è causato da una mancanza di una base di dati delle sessioni comuni. Per porre rimedio a questo si usa per l appunto una base di dati delle sessioni in modo che ciascun possa recuperare i dati della sessione in seguito ad un malfunzionamento. Questo tipo di soluzione è però costoso in termini di prestazioni; si può allora adottare una soluzione mista dove i dati di sessione sono ospitati in memoria centrale del motore degli script e una copia degli stessi nella base di dati per evitare perdite in caso di malfunzionamento. La replicazione del web può essere sfruttata anche per migliorare la sicurezza della trasmissione dei dati in quanto uno dei replicati può essere equipaggiato con la versione sicura di in grado di supportare la crittografia dei dati trasmessi attraverso una richiesta. Configurazione con application La configurazione prima esposta può essere resa più scalabile e modulare estendendo lo strato intermedio con un application. WebServer1 Engine 1 Host 2 S WebServer2 Engine 2 Database DMZ WebServer3 Engine 3 I diversi strati di questa configurazione fanno uso di replicazione e clustering. Il principale beneficio che viene apportato dagli application è la centralizzazione della logica di business in un sottostrato dedicato il quale gestisce le risorse condivise, la replicazione trasparente degli oggetti di business, il bilanciamento del carico ed il ripristino dai guasti. Il parallelismo dell application è dinamico a differenza delle altre configurazioni, ovvero l application decide a tempo di esecuzione il numero di processi da allocare a ciascun componente di business in base al traffico reale.

5 Con questo metodo più applicazioni possono coesistere sulla stessa macchina assicurando maggiori risorse all applicazione che sta sostenendo il maggior carico di lavoro. Un altro beneficio derivante dagli application sta nel fatto che viene incoraggiato lo sviluppo di componenti di business riusabili. Gli oggetti di business dell application sono una piattaforma per l integrazione delle applicazioni aziendali in quanto nell application si possono sviluppare ed installare funzioni utili a livello di intera azienda che vengono utilizzate da qualsiasi tipo di client. Per far fronte alle diverse esigenze di sicurezza di client eterogenei l application può essere inserito in una zona demilitarizzata separata in maniera tale che utenti fidati possano accedere all application pur rimanendo separati dalla intranet più interna che ospita lo strato dei dati. WebServer1 Engine 1 Host 2 S WebServer2 Engine 2 Database DMZ WebServer3 Engine 3 DMZ2 Ricapitolando quanto già detto possiamo così dettagliare la valutazione di questo tipo di configurazione: Prestazioni: elevate grazie al load-balancing dinamico Scalabilità: virtualmente illimitata replicando l application Disponibilità: capacità di fail-over a livello degli oggetti eseguiti all interno dell application, gestione delle transazioni Complessità: ambienti generalmente complessi da manutenere Il pattern MVC Un metodo per distribuire le funzionalità software tra web ed application è il pattern MVC. Questa architettura è concepita per meglio separare ed isolare le tre funzioni essenziali di un applicazione interattiva: La logica di business dell applicazione (modello); L interfaccia di presentazione all utente (vista); Il controllo dell interazione che si determina a seguito delle azioni dell utente (controllore). Il tipic o flusso è il seguente: L elaborazione è attivata da una richiesta dell utente nei confronti di un certo servizio; la richiesta è intercettata da un controllore che decide l azione da intraprendere, esso trasferisce la richiesta ad un modello ed infine esso elabora la richiesta e notifica alla vista che presenta i dati al client.

6 Questo tipo di architettura prescrive una netta separazione delle responsabilità tra i componenti dell applicazione: Il modello incorpora le azioni di business necessarie a far fronte a richieste dell utente, inoltre mantiene lo stato dell applicazione; La vista racchiude la logica di presentazione con cui si assembla l interfaccia utente; Il controllore ha la responsabilità di interpretare la richiesta dell utente, produrre un adeguata richiesta d azione, esaminare il risultato di ogni azione e decidere il passo successivo; Le azioni sono i componenti che implementano la logica di business. Architettura MVC adattata alle applicazioni web Nell architettura MVC2 il generatore delle richieste di servizio è il browser. Quando l utente attiva una richiesta questa viene inviata al che la trasferisce al servlet container dove è intercettata da un programma che funge da controllore; questo decide la sequenza di azioni necessarie a soddisfare ogni richiesta, le azioni ammissibili sono contenute nel modello sotto forma di componenti. Il controllore associa le richieste alla corrispondente azione creando un oggetto della classe action e chiamando una delle sue funzioni. Una classe action è una classe Java che racchiude una particolare funzione applicativa che agisce sullo stato dell applicazione. In scenari semplici una classe action implementa tutta la logica di business necessaria a servire la richiesta. Se l azione necessita di modificare lo stato dell applicazione essa può modificare particolari oggetti del modello (oggetti di stato). Dopo lo svolgimento del proprio compito l azione comunica il risultato dell esecuzione al controllore che decide il passo successivo. Alla fine il controllore invoca un template di pagina JSP che fa parte della vista, questo è responsabile di presentare all utente il nuovo stato dell applicazione. Prestazioni delle architetture web Generalmente il punto di partenza per il dimensionamento dell architettura e successivamente per la verifica delle sue prestazioni è la definizione dei requisiti di prestazione. Questo tipo di attività consiste nello stimare il numero ed il tipo di richieste per pagina oltre al tempo di risposta. I parametri che vanno valuti in un attività di questo tipo sono: Numero di richieste di pagina: valore medio e di picco delle richieste provenienti dai client espressi in pagine per secondo(esprime il traffico dell applicazione come percepito dall utente) ; Numero di utenti concorrenti: esprime la stima del numero medio e massimo di utenti che accederanno simultaneamente all applicazione;

7 Tempo di risposta: numero massimo di secondi che l utente è costretto ad attendere prima di ricevere la risposta; Mescolanza di richieste: associazione di un peso ad ogni pagina che denota la probabilità che un utente acceda alla pagina durante una sessione interattiva. La parte più difficile in questo meccanismo di valutazione ed aggiustamento delle prestazione è la comprensione del comportamento dell applicazione e della sua configurazione. In u n sistema complesso le prestazioni sono limitate dal componente più lento definito come collo di bottiglia. È quindi indispensabile individuare il collo di bottiglia del sistema al fine di capire cosa modificare. Un possibile algoritmo per questa fase può essere il seguente: Start Requisiti di performance Rimuovi colli di bottiglia (se possib.) Definisci una configurazione Identifica colli di bottiglia Verifica performance no Requisiti soddisfatti? sì Stop Una volta che il collo di bottiglia è stato identificato possono essere adottate diverse strategie al fine di risolvere il problema: Modificare il codice dell applicazione; Estendere la configurazione dell architettura; Introdurre meccanismi di caching. Il caching consiste nel memorizzare temporaneamente le risorse in una locazione ad accesso veloce da cui sia possibile recuperarle poi. Nell ambito delle applicazioni web il caching viene applicato a tutte le risorse coinvolte nel calcolo della risposta ad una richiesta formulata dall utente partendo dall intera pagina HTML per arrivare al singolo risultato di una interrogazione sulla base di dati. Le tecniche di caching web garantiscono due benefici fondamentali: Riduzione della latenza di rete: se la cache è più vicina al client che al, il percorso che la risorsa deve compiere è più breve e di conseguenza si ha un risparmio di banda e di tempo di risposta; Riduzione dello sforzo di calcolo: se la risorsa è costruita dinamicamente utilizzarne una copia memorizzata in cache riduce lo sforzo di riassemblamento. In generale un meccanismo di cache fa da intermediario tra le richieste dell utente e l applicazione che produce le risposte. Qualsiasi elemento che contribuisce alla risposta può essere messo in cache: Pagine statiche Files multimediali Fammenti di pagine dinamiche computate

8 Dati intermedi consumati dallo scripting per computare pagine Risultati di queries a database o di altre computazioni Siccome diverse parti dell architettura sono in grado di sopportare diversi meccanismi di caching dobbiamo analizzare le possibili modalità di implementazione: Caching sul browser: ogni browser contiene una cache con l obbiettivo di velocizzare la composizione delle pagine che contengono oggetti già in cache. Questa cache è una directory sul disco fisso dell utente. Questo meccanismo non è però stabile in quanto il client o il produttore possono disabilitarlo; Proxy caching: è una cache posta a lato interposta tra una varietà di utenti. Questo tipo di cache memorizza una copia locale di ciascuna risorsa richiesta dagli utenti ed evita l accesso alla rete internet per recuperare pagine richieste frequentemente. Si ottengono benefici in termini di consumo di banda e tempo di risposta; essi sono generalmente implementati insieme a in quanto attraverso quest ultimi fluiscono le richieste; Reti di erogazione dei contenuti (Content Delivery Network): sono infrastrutture di caching interposte tra chi consuma e chi produce i contenuti; viene generalmente utilizzata per servire un vasto numero di utenti internet distribuiti geograficamente. La rete CDN soddisfa le richieste dell utente utilizzando molteplici nodi di caching e sofisticate politiche di erogazione dei contenuti, in grado di selezionare la copia ottimale della pagina in base alla posizione geografica dell utente e alle condizioni di traffico in tempo reale; Acceleratori di : è una soluzione implementata dal produttore dei contenuti, si tratta di un buffer posizionato davanti a un cluster avente la funzione di intercettare tutte le richieste indirizzate al cluster, memorizzando copie degli oggetti prodotti dai e restituendole durante le successive richieste. Quand o viene implementata una infrastruttura di caching l aspetto più critico riguarda la gestione delle copie dei contenuti in quanto si richiede la soluzione di due problemi: Riempimento della cache: modalità con cui viene popolata la cache; Aggiornamento della cache: modo in cui i contenuti vengono invalidati e di conseguenza aggiornati. Il riempimento può essere fatto attraverso tecniche di pushing o di pulling dei contenuti. L approccio di tipo pushing richiede il trasferimento in massa dei contenuti dalla posizione di origin e della cache; questo viene fatto off-line periodicamente ed è indipendente dalle richieste del client. L appr occio invece di tipo pulling è la modalità classica di gestione della cache; i contenuti vengono trasferiti dal di origine alla cache in seguito alla richiesta del client: se l oggetto è già in cache viene restituito altrimenti la richiesta viene girata al di origine che produce l oggetto ed aggiorna i contenuti della cache.con questo tipo di approccio i contenuti non sono aggiornati periodicamente ma ogni oggetto viene gestito individualmente e risiede nella cache per una durata stabilita dal protocollo di invalidazione della cache. Questo protocollo consiste in un insieme di regole per lo scambio delle richieste e risposte tra la cache ed il mirate ad assicurare la validità delle risorse trasferite al client. 1.1 contiene un protocollo di invalidazione basato su due regole: Regole di scadenza (Expiration rules): impongono la durata di un oggetto nella cache; Regole di invalidazione (Invalidation rules): definiscono i criteri per verificare se la copia dell oggetto non è più conforme all oggetto originale. I protocolli di invalidazione per oggetti dinamici (come pagine jsp) sono più complessi in quanto possono dipendere da contenuti aggiornati in modo indipendente da più applicazioni; il problema consiste nel capire gli aggiornamenti dei contenuti e nel notificarli alla cache in maniera tale che possa aggiornare la copia dell oggetto modificato.