Meccanismi per la redirezione delle richieste in sistemi di server Web distribuiti geograficamente

Transcript

1 Tesi di Laurea Meccanismi per la delle richieste in sistemi di server Web distribuiti geograficamente Candidato: Serena Ramovecchi Relatore: Prof. Salvatore Tucci Correlatrice: Ing. Valeria Cardellini Sommario Sviluppo di Internet, traffico e soluzioni Server Web distribuiti geograficamente Prototipo: progetto ed implementazione Testing Risultati sperimentali Conclusioni e sviluppi futuri

2 Internet: crescita esponenziale Host collegati Gennaio Luglio Gennaio Luglio Gennaio Luglio Gennaio Luglio Gennaio Luglio Gennaio Luglio Gennaio Luglio Gennaio Luglio Gennaio Fonte: Internet Software Consortium ( Numero di host (in milioni) dal 1997 ad oggi gen-97 lug-97 gen-98 lug-98 gen-99 lug-99 gen-00 lug-00 gen-01 Soluzioni: caching mirroring content distribution network architetture di server Web distribuiti locali geografiche Server Web distribuiti geograficamente: Event Period Peak day Peak minute Peak second NCSA server (Oct. 1995) - 2 Million - - Olympic Summer Games 192 Million 8 Million - - (Aug. 1996) (17 days) Nasa Pathfinder 942 Million 40 Million - - (July 1997) (14 days) Olympic Winter Games Million 55 Million 110,000 1,800 (Feb. 1998) (16 days) Wimbledon (July 1998) ,000 2,400 FIFA World Cup 1,350 Million 73 Million 209,000 3,500 (July 1998) (84 days) Wimbledon (July 1999) Million 430,000 7,200 Wimbledon (July 2000) Million 964,000 16,000 Olympic Summer Games Million 1,200,000 20,000 (Sept. 2000) # contatti Throughput richiesto: 20,000/sec * 10KB = 200MB/sec => Server Web distribuiti geograficamente: più punti di accesso alle risorse distribuzione del carico fault tolerance

3 Server Web distribuiti geograficamente: Distribuzione delle richieste 1 livello: DNS 2 livello: server Web DNS locale ADNS del sito resolver client richiesta HTTP pagina 302 Internet pagina richiesta Obiettivo del lavoro di tesi: Realizzare un server Web in grado di effettuare la delle richieste in ambito geografico

4 Progetto del prototipo: Processo di composto da 4 fasi: Attivazione Scopo: utilizzare la solo quando l overhead introdotto può essere compensato da una diminuzione del T risposta Selezione Localizzazione Redirezione Server client http 1 syn syn, ack ack richiesta http syn, ack richiesta http syn ack pagina Server http 2 Scenario di una http Overhead della Attivazione basata su una soglia di carico Progetto del prototipo: Processo di in 4 fasi: Attivazione Selezione Scopo: redirigere solo le richieste t.c. T processamento compensa l overhead della Politiche di Localizzazione Redirezione statiche dinamiche

5 Progetto del prototipo: Processo di in 4 fasi: Attivazione Selezione Scopo: individuare il target server Politiche di Localizzazione statiche dinamiche Redirezione Scopo: effettuare la HTTP Progetto del prototipo: Algoritmo Controlli Attendi la richiesta è già stata rediretta? E' arrivata una nuova richiesta HTTP? Sì No l utilizzazione del server supera la soglia? Sì La richiesta è già stata rediretta? No Ricava il carico del sistema Funzionalità calcolo dell utilizzazione del server Sì carico > soglia No della Attiva la

6 Progetto del prototipo: Algoritmo Controlli la è stata attivata? La è stata attivata? No Funzionalità Sì Individua il criterio di da applicare Esegui la effettuare la : random in base alle proprietà del documento (dimesioni e numero di oggetti nascosti) in base al tipo di documento Progetto del prototipo: Algoritmo Controlli La ha abilitato la? Sì Individua il criterio di da applicare Scegli il server di destinazione in base al criterio No la è stata abilitata? Funzionalità effettuare la : random round Robin

7 Progetto del prototipo: Algoritmo Controlli La ha abilitato la? No la è stata abilitata? Sì Funzionalità Recupera l'informazione sul server di destinazione Invia al client un messaggio di con l'informazione sul nuovo server da contattare restituire al client un header HTTP contenente: il codice HTTP 302 l IP del target server Implementazione: il server Web Apache Diffusione: ad Agosto 2002 il 66% dei siti Web utilizzava Apache Disponibilità del codice sorgente Struttura modulare: caricando solo i moduli necessari non si consumano risorse inutilmente semplicità nell estensione del codice Moduli standard di Apache Moduli del prototipo Nucleo di Apache

8 Implementazione: il prototipo Moduli del prototipo Parametri di configurazione Soglia di carico Max/ media Pesi dei fattori di carico Modulo di Redirezione:On/off %CPU %disco Tool monitor Calcola ciclicamente l utilizzazione di CPU e disco Memorizza i risultati in un file parser di report cpu cpu page swap 1 0 intr disk_io: (3,0):(7473,7255,101892,218,3582) ctxt btime processes 1060 Contenuto del file /proc/stat di Linux Implementazione: il prototipo Moduli del prototipo Redirezione On dal Modulo di Parametri di configurazione Criterio di Tipo MIME Modulo di Redirezione: abilitata/disabilitata Tool monitor parser Criteri di : Redirect all Preprocessa i documenti Random del sito calcolando size e #oggetti embedded Per tipo Calcola i valori medi Per Memorizza proprietà i risultati in un file di report size # oggetti embedded doc: /home/serena/apa/www/htdocs/appendix/changes.html doc: /home/serena/apa/www/htdocs/index/elements.html doc: /home/serena/apa/www/htdocs/interact/forms.html doc: /home/serena/apa/www/htdocs/types.html num_parsed_files: 31 avg_embed_obj_num: 1 avg_doc_size: Contenuto del file di report

9 Implementazione: il prototipo Moduli del prototipo Redirezione abilitata dal Modulo di Parametri di configurazione Politica di Modulo di Target server Tool monitor Politiche stateless: Random Round Robin Target server: Elenco server del sito parser (es. Implementazione: il prototipo Moduli del prototipo Target server dal Modulo di Modulo di Header HTTP Tool monitor parser Header HTTP della risposta Status code: HTTP 302 (moved temporarily) Location: stringa ottenuta dal modulo di (es.

10 Testing: httpget_test I benchmark esistenti (ad es. Webstone, httperf e SPECweb) non supportano la Sviluppo del tool httpget_test httpget_test: client HTTP interpreta il codice HTTP 302 misura: Trisposta server 1 Client T look up T connect T 1 byte DNS Server1 Server2 T lookup T lookup T connessione Trestante T connessione T al 1 byte T al 1 byte T restante di trasferimento T restante di trasferimento T risposta dal 1 server T risposta dal 1 server T risposta dal 2 server T risposta dal 2 server memorizza i risultati Trisposta server 2 T connect T 1 byte Trestante Testing: piattaforma Sistema locale aemilianus PIV1.8GHz, 1GB RAM traianus PII450MHz, 256MB RAM Sistema remoto jive PIII865MHz, 512MB RAM Internet client LAN a 100Mbit/sec client salsa PII450MHz, 256MB RAM Scopo: misurare l efficacia della in funzione dell utilizzazione del server Scopo: verificare i risultati in locale considerando l impatto di rete, a parità di distanza client-server

11 Testing: scenari Test: diurni, notturni Utilizzazione del server: File campione: 1KB, 10KB, 100KB, 1MB scarico carico (50%, 70%, 90%) Classificazione degli scenari di testing Scenari di testing Senza Con Server scarico Server carico Server1 scarico Server2 scarico Server1 carico Server2 scarico Server1 scarico Server2 carico Server1 carico Server2 carico Risultati sperimentali: sistema locale Aumento Riduzione del del T T risposta : : utilizzazione server1 >= 70% scarico documenti 100KB-1MB inversamente proporzionale al carico del server2 Validità dell della in base ad una soglia di carico Overhead della compensato dal T processamento su server carico 50 T risposta (ms) 0 Test diurno su file da 100KB Server1 carico al 90% Server2 scarico Media Mediana 90 percentile Senza Con

12 Risultati sperimentali: sistema remoto Conferma dei risultati in locale: l impatto della rete non modifica i risultati ottenuti considerando la sola utilizzazione dei server Utilità della per l incremento delle prestazioni 25 T risposta (sec) 0 Test notturno su file da 1MB Server1 carico al 90% Server2 scarico Media Mediana 90 percentile Senza Con Conclusioni e sviluppi futuri Conclusioni Realizzazione di un prototipo di server Web in grado di supportare la delle richieste in ambito geografico Monitoraggio del livello di carico del sistema Parsing dei documenti del sito Sviluppo di un tool per il benchmarking del prototipo Sviluppi futuri Attivazione: soglia di carico dinamica Selezione: nuovi criteri Localizzazione: politiche basate sul carico e sulla prossimità Redirezione: Javascript e URL rewriting Utilizzo di piattaforme di testing più estese