Che cos’è, a cosa serve e come funziona la Web Replication (replicazione di dati)

Che cos’è, a cosa serve e come funziona la Web Replication (replicazione di dati)

Web Replication

La tecnologia di Web Replication è utilizzata per la replicazione di dati e servizi su server dislocati in differenti aree geografiche. In questo paragrafo descriviamo brevemente i principi che ispirano le tecniche utilizzate per il collegamento dinamico di un utente alla replica “più conveniente”, cioè le tecniche e le politiche di distribuzione che possono essere utilizzate nel bilanciamento del carico. In letteratura si differenziano tra strategie di distribuzione Mirror-based, che indirizzano il browser verso la replica geograficamente più vicina, tecniche DNS-based che, nella configurazione più semplice, distribuiscono il carico utilizzando una politica round robin (basata su una rigida rotazione degli indirizzi IP) e tecniche più sofisticate QoS-based (basate sulla Qualità del Servizio), che mirano ad ottimizzare l’URT (User Response Time), il tempo di risposta per l’utente, inteso come l’intervallo temporale che intercorre tra l’istante in cui l’utente effettua una richiesta e il rendering completo della pagina da parte del browser.

Che cos'è, a cosa serve e come funziona la Web Replication (replicazione di dati)

Le strategie di distribuzione del carico, sono classificabili in statiche e dinamiche. Le tecniche statiche, solitamente, si basano su algoritmi deterministici o stocastici, utilizzando informazioni riguardanti il carico medio dei sistemi, piuttosto che quello corrente (current workload). Per questo, anche se la loro implementazione risulta di limitata complessità, spesso possono condurre a prestazioni non soddisfacenti.

Le tecniche adattive implementano il bilanciamento del carico, reagendo dinamicamente ai cambiamenti dello stato del sistema. In generale, queste tecniche sono intrinsecamente più complesse di quelle statiche, poiché necessitano di mantenere informazioni a run-time, in modo da rispondere a possibili cambiamenti dello stato, ma sono sicuramente più efficaci. La distribuzione adattiva del carico dei server web, comunque, non è facile da ottenere, poiché la sua implementazione richiede un binding (collegamento) dinamico dei browser verso i server web. Il binding dinamico verso la replica “più conveniente” diviene difficile, a causa della tendenza ad utilizzare schemi di naming basati su locazione. Poiché le URL contengono l’hostname del server e la locazione della risorsa su uno specifico server, c’è un mapping intrinseco tra l’istanza di una risorsa e la sua locazione. Questo rende difficile la distribuzione del carico tra un certo numero di macchine, senza aumentare la “smartness” del software dal lato client. Da queste problematiche è, anche, nata l’esigenza di definire le URN.

In particolare, poiché i client accedono alle risorse specificando direttamente l’hostname del server, le tecniche che regolano il collegamento dinamico di un client ad un insieme di server (senza un qualsiasi aumento del traffico di messaggi in rete) devono gestire il binding dell’indirizzo IP corrispondente al nome di host e/o il routing del messaggio.
Per abilitare un certo numero di macchine a condividere indirizzi IP sono state sviluppate diverse soluzioni. Per esempio, per aumentare progressivamente la potenza di calcolo su un dato sito, l’implementazione di un servizio web può essere basata su un cluster di macchine cooperanti localmente distribuite, accedute tramite un singolo indirizzo IP, utilizzando una tecnica chiamata NAT (Network Address Translation).

Un approccio alternativo per la distribuzione del carico è fare uso della funzionalità di redirezione (redirect) del protocollo HTTP, che redirige le richieste dei client in arrivo verso un server, facente parte di un insieme di repliche. I client fanno una connessione iniziale al server principale (a cui punta la URL) ed esso risponde con un codice HTTP 302 (found: la risorsa richiesta risiede temporaneamente sotto una differente URL), indicando il server a cui fare riferimento. Quindi, il client invia la richiesta corrente (e le successive) al server specificato. Questo meccanismo ha, comunque, lo svantaggio di rendere visibili le URL di tutti i server disponibili, che potrebbero essere memorizzate in hot-list o indicizzate da motori di ricerca, rendendo quindi inefficiente il bilanciamento del carico

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *