ݺߣ

ݺߣShare a Scribd company logo

Presentazione tesi magistrale

•
•
Federico Cacco
Federico Cacco

Negli ultimi anni l'utilizzo di piattaforme Cloud per la fornitura di servizi web sta diventando una soluzione sempre più diffusa ed economicamente vantaggiosa, ma che a volte non sembra essere stata ancora ben assimilata da parte di chi si occupa della progettazione e sviluppo dei servizi. In questa tesi si è dunque voluto dare una descrizione di come vada progettata l'architettura di un'applicazione che possa essere efficientemente utilizzata in piattaforme cloud, così da poter sfruttarne al meglio le caratteristiche e gli strumenti li' messi a disposizione. Per far ciò sono state dapprima studiate le principali differenze che sussistono tra una piattaforma non cloud ed una cloud. Per dare maggior validità al lavoro svolto è stato preso in esame GeoServer, uno dei server geospaziali open source maggiormente utilizzati progettato ancora secondo un'architettura client/server classica, ma che dati i servizi offerti trarrebbe molti vantaggi da un suo utilizzo in ambienti Cloud. Sono stati quindi individuati i limiti architetturali di GeoServer che non ne consentono un buon utilizzo su piattaforme cloud, proponendo poi delle modifiche che consentono il superamento di tali limiti mantenendone comunque inalterate le funzionalità. Infine sono stati condotti dei test, usando come piattaforma Cloud Amazon AWS, per dimostrare i vantaggi della nuova architettura e confrontare alcune possibili alternative d'implementazione.

1 of 22
Downloaded 12 times
GeoServer nel Cloud Un caso di studio sulle modifiche architetturali nel passaggio a piattaforme Cloud Federico Cacco Laurea Magistrale in Informatica Universit` degli Studi di Padova a Dipartimento di Matematica 11 Ottobre 2013
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Sommario 1 Scopo del progetto 2 Approccio architetturale per la risoluzione delle problematiche affrontate 3 Caso d’uso reale per verificare le soluzioni proposte 4 Ambiente Cloud utilizzato per implementare l’architettura proposta 5 Test effettuati 6 Conclusioni 7 Sviluppi futuri Federico Cacco – GeoServer nel Cloud 2/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Scopo del progetto Le architetture delle piattaforme Cloud sono del tutto diverse da quelle convenzionali Applicazioni ⇒ Fornite come servizi web Istanza ⇒ Entit` operativa che fruisce i servizi a Elasticit` ⇒ Capacit` di adattarsi (scaling) all’esigenza corrente a a Ottenuta mediante la replicazione delle istanze Applicazioni progettate per piattaforme convenzionali sono inadeguate agli ambienti Cloud Quali considerazioni architetturali sono necessarie? Federico Cacco – GeoServer nel Cloud 3/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Scomposizione dei servizi Necessario replicare solamente i componenti che ne hanno reale necessit` a Tutti i servizi in una unica istanza Per scalare un servizio devo replicare l’istanza che fornisce tutti i servizi Una servizio per istanza Per scalare un servizio posso replicare solamente l’istanza che lo fornisce Federico Cacco – GeoServer nel Cloud 4/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Rete di Dispatcher La replicazione delle istanze che compongono il web server deve essere trasparente L’utente non deve preoccuparsi di inviare la richiesta all’istanza in quel momento libera Deve essere presente un unico punto d’accesso al web server Indipendentemente dal numero di replicazioni e dal numero di servizi forniti Soluzione: Rete di dispatcher Secondo livello: Gestisce replicazioni di istanze che forniscono lo stesso servizio Bilancia il carico di lavoro Primo livello Instrada le chiamate al corretto dispatcher di secondo livello Espone un unico punto d’accesso al web server Federico Cacco – GeoServer nel Cloud 5/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Configurazione comune delle istanze Tutte le istanze devono avere la medesima configurazione Modifiche alla configurazione di una istanza devono ripercuotersi su tutte le altre Soluzione 1: Configurazione in uno spazio condiviso Soluzione 2: Configurazione locale sincronizzata La scelta dipende dall’architettura dei servizi e dalla piattaforma Cloud utilizzata Federico Cacco – GeoServer nel Cloud 6/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Memorizzazione dei dati Database soggetto a numerosi accessi simultanei Necessit` di una sua distribuzione a Partizionamento Replicazione Federico Cacco – GeoServer nel Cloud 7/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Visione d’insieme Federico Cacco – GeoServer nel Cloud 8/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri GeoServer Caso di studio concreto: GeoServer Server web geospaziale che fornisce i servizi Web Coverage Service Web Feature Service Web Map Service Servizi con differenti carichi computazionali Scomposizione per poter avviare istanze contenenti i singoli servizi Federico Cacco – GeoServer nel Cloud 9/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Strumenti AWS utilizzati Ambiente Cloud utilizzato: Amazon Web Services Metrica per lo scaling ⇒ Latenza Rilevata nei Load Balancer di secondo livello Federico Cacco – GeoServer nel Cloud 10/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Strumenti esterni ad AWS utilizzati Dispatcher di primo livello S3FS (Middleware supporto S3) Pgpool-II (Middleware di distribuzione) PostgreSQL (Data Base Management System) PostGIS (Estensione per dati geospaziali) Federico Cacco – GeoServer nel Cloud 11/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Regioni e Availability Zone Regione: Sedi su cui ` collocato AWS nel mondo e Availability Zone: Sotto suddivisione delle Regioni Le Availability Zone consentono di implementare architetture affidabili impedendo la diffusione dei guasti Federico Cacco – GeoServer nel Cloud 12/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Visione d’insieme Federico Cacco – GeoServer nel Cloud 13/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Configurazione dei test Simulati utenti contemporanei che invocano i servizi 2 serie di dati geospaziali suddivisi in 2 workspace sf (citt` di Spearfish, South Dakota) a tiger (citt` di New York) a 2 configurazioni di distribuzione della base di dati Partizionamento Replicazione Federico Cacco – GeoServer nel Cloud 14/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Availability Zone La distribuzione nelle Availability Zone per aumentare l’affidabilit` introduce latenze? a Simulati 5 utenti contemporanei Richiesta WMS getMap WMS getMap WMS getMap (sf) WMS getMap (tiger) Lat. media (ms) (sf) (tiger) multilayer 3 svg multilayer 3 svg Totale Diversa AZ Throughput (rich/sec) Stessa AZ Lat. media (ms) Throughput (rich/sec) 606 580 1,6180 1,7667 625 586 1,6662 1,6785 943 1,7620 1001 1,6722 2412 1,7518 2610 1,6360 1134 6,9874 1205 6,5174 Distribuire l’applicazione tra pi` Availability Zone non introduce latenze u Federico Cacco – GeoServer nel Cloud 15/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Partizionato VS Replicato - 2 workspace La distribuzione mediante partizionamento ` pi` efficiente nel caso di richieste riferite a e u workspace diverse? Simulati 16 utenti contemporanei DB partizionato Lat. media Throughput (ms) (rich/sec) Richiesta WMS getMap WMS getMap WMS getMap (sf) WMS getMap (tiger) (sf) (tiger) multilayer 3 svg multilayer 3 svg Totale DB replicato Lat. media Throughput (ms) (rich/sec) 524 577 3,4943 3,4895 818 807 2,7626 2,7604 975 3,4847 1322 2,7477 2516 3,4379 2870 2,7571 1146 13,7263 1452 10,8429 Con chiamate relative a dati in differenti workspace la distribuzione mediante partizionamento risulta pi` efficiente u Federico Cacco – GeoServer nel Cloud 16/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Partizionato VS Replicato - 1 workspace La distribuzione mediante replicazione ` pi` efficiente nel caso di richieste riferite sempre e u alla stessa workspace? Simulati 16 utenti contemporanei DB partizionato Lat. media Throughput (ms) (rich/sec) Richiesta WMS getMap WMS getMap (tiger) WMS getMap (tiger) WMS getMap (tiger) (tiger) multilayer 3 svg multilayer cql multilayer filter Totale DB replicato Lat. media Throughput (ms) (rich/sec) 634 3,2172 1021 2,6029 2972 3,1615 3227 2,5524 684 3,2058 925 2,5952 693 3,1974 989 2,5944 1248 12,5958 1542 10,1734 Distribuzione mediante partizionamento nuovamente pi` efficiente u Per piccole distribuzioni il middleware non introduce benefici Federico Cacco – GeoServer nel Cloud 17/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Test sullo scaling up Lo scaling up riduce la latenza quando essa diventa eccessiva? Soglie scaling: Scaling up: lat. > 15 s (MAX) Latenza ridotta dallo scaling up Ritardo tra allarme ed effettiva diminuzione della latenza Federico Cacco – GeoServer nel Cloud 18/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Test sullo scaling down Vengono liberate le risorse quando non sono pi` necessarie? u Soglie scaling: Scaling up: lat. > 15 s (MAX) Scaling down: lat. < 1 s (MED) Tempo attivazione istanza > Tempo disattivazione istanza Federico Cacco – GeoServer nel Cloud 19/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Test sullo scaling down - oscillazione Importante utilizzare soglie di scaling corrette! Soglie scaling: Scaling up: lat. > 10 s (MAX) Scaling down 1: lat. < 1 s (MED) Scaling down 2: lat. < 0.6 s (MED) Oscillazione dovuta ad una soglia di scaling down troppo alta Federico Cacco – GeoServer nel Cloud 20/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Conclusioni La latenza si rivela una buona metrica per determinare se il dimensionamento ` e coerente con il carico di lavoro Rendere l’architettura pi` affidabile mediante una sua distribuzione su pi` u u Availability Zone non ne pregiudica le prestazioni Nel caso di richieste fatte a pi` workspace, la distribuzione mediante u partizionamento si rileva pi` efficiente di quella realizzata mediante replicazione u Lo scaling up ` una operazione molto pi` onerosa, in termini di tempo e risorse, e u dello scaling down Difficile determinare soglie di scaling corrette Federico Cacco – GeoServer nel Cloud 21/ 22
Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Scomposizione servizi Predire i picchi di carico in modo da anticipare lo scaling dei servizi ⇒ Testare la distribuzione mediante replicazione con scaling up di dimensioni maggiori Federico Cacco – GeoServer nel Cloud 22/ 22

More Related Content

Presentazione tesi magistrale

  • 1. GeoServer nel Cloud Un caso di studio sulle modifiche architetturali nel passaggio a piattaforme Cloud Federico Cacco Laurea Magistrale in Informatica Universit` degli Studi di Padova a Dipartimento di Matematica 11 Ottobre 2013
  • 2. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Sommario 1 Scopo del progetto 2 Approccio architetturale per la risoluzione delle problematiche affrontate 3 Caso d’uso reale per verificare le soluzioni proposte 4 Ambiente Cloud utilizzato per implementare l’architettura proposta 5 Test effettuati 6 Conclusioni 7 Sviluppi futuri Federico Cacco – GeoServer nel Cloud 2/ 22
  • 3. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Scopo del progetto Le architetture delle piattaforme Cloud sono del tutto diverse da quelle convenzionali Applicazioni ⇒ Fornite come servizi web Istanza ⇒ Entit` operativa che fruisce i servizi a Elasticit` ⇒ Capacit` di adattarsi (scaling) all’esigenza corrente a a Ottenuta mediante la replicazione delle istanze Applicazioni progettate per piattaforme convenzionali sono inadeguate agli ambienti Cloud Quali considerazioni architetturali sono necessarie? Federico Cacco – GeoServer nel Cloud 3/ 22
  • 4. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Scomposizione dei servizi Necessario replicare solamente i componenti che ne hanno reale necessit` a Tutti i servizi in una unica istanza Per scalare un servizio devo replicare l’istanza che fornisce tutti i servizi Una servizio per istanza Per scalare un servizio posso replicare solamente l’istanza che lo fornisce Federico Cacco – GeoServer nel Cloud 4/ 22
  • 5. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Rete di Dispatcher La replicazione delle istanze che compongono il web server deve essere trasparente L’utente non deve preoccuparsi di inviare la richiesta all’istanza in quel momento libera Deve essere presente un unico punto d’accesso al web server Indipendentemente dal numero di replicazioni e dal numero di servizi forniti Soluzione: Rete di dispatcher Secondo livello: Gestisce replicazioni di istanze che forniscono lo stesso servizio Bilancia il carico di lavoro Primo livello Instrada le chiamate al corretto dispatcher di secondo livello Espone un unico punto d’accesso al web server Federico Cacco – GeoServer nel Cloud 5/ 22
  • 6. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Configurazione comune delle istanze Tutte le istanze devono avere la medesima configurazione Modifiche alla configurazione di una istanza devono ripercuotersi su tutte le altre Soluzione 1: Configurazione in uno spazio condiviso Soluzione 2: Configurazione locale sincronizzata La scelta dipende dall’architettura dei servizi e dalla piattaforma Cloud utilizzata Federico Cacco – GeoServer nel Cloud 6/ 22
  • 7. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Memorizzazione dei dati Database soggetto a numerosi accessi simultanei Necessit` di una sua distribuzione a Partizionamento Replicazione Federico Cacco – GeoServer nel Cloud 7/ 22
  • 8. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Visione d’insieme Federico Cacco – GeoServer nel Cloud 8/ 22
  • 9. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri GeoServer Caso di studio concreto: GeoServer Server web geospaziale che fornisce i servizi Web Coverage Service Web Feature Service Web Map Service Servizi con differenti carichi computazionali Scomposizione per poter avviare istanze contenenti i singoli servizi Federico Cacco – GeoServer nel Cloud 9/ 22
  • 10. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Strumenti AWS utilizzati Ambiente Cloud utilizzato: Amazon Web Services Metrica per lo scaling ⇒ Latenza Rilevata nei Load Balancer di secondo livello Federico Cacco – GeoServer nel Cloud 10/ 22
  • 11. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Strumenti esterni ad AWS utilizzati Dispatcher di primo livello S3FS (Middleware supporto S3) Pgpool-II (Middleware di distribuzione) PostgreSQL (Data Base Management System) PostGIS (Estensione per dati geospaziali) Federico Cacco – GeoServer nel Cloud 11/ 22
  • 12. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Regioni e Availability Zone Regione: Sedi su cui ` collocato AWS nel mondo e Availability Zone: Sotto suddivisione delle Regioni Le Availability Zone consentono di implementare architetture affidabili impedendo la diffusione dei guasti Federico Cacco – GeoServer nel Cloud 12/ 22
  • 13. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Visione d’insieme Federico Cacco – GeoServer nel Cloud 13/ 22
  • 14. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Configurazione dei test Simulati utenti contemporanei che invocano i servizi 2 serie di dati geospaziali suddivisi in 2 workspace sf (citt` di Spearfish, South Dakota) a tiger (citt` di New York) a 2 configurazioni di distribuzione della base di dati Partizionamento Replicazione Federico Cacco – GeoServer nel Cloud 14/ 22
  • 15. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Availability Zone La distribuzione nelle Availability Zone per aumentare l’affidabilit` introduce latenze? a Simulati 5 utenti contemporanei Richiesta WMS getMap WMS getMap WMS getMap (sf) WMS getMap (tiger) Lat. media (ms) (sf) (tiger) multilayer 3 svg multilayer 3 svg Totale Diversa AZ Throughput (rich/sec) Stessa AZ Lat. media (ms) Throughput (rich/sec) 606 580 1,6180 1,7667 625 586 1,6662 1,6785 943 1,7620 1001 1,6722 2412 1,7518 2610 1,6360 1134 6,9874 1205 6,5174 Distribuire l’applicazione tra pi` Availability Zone non introduce latenze u Federico Cacco – GeoServer nel Cloud 15/ 22
  • 16. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Partizionato VS Replicato - 2 workspace La distribuzione mediante partizionamento ` pi` efficiente nel caso di richieste riferite a e u workspace diverse? Simulati 16 utenti contemporanei DB partizionato Lat. media Throughput (ms) (rich/sec) Richiesta WMS getMap WMS getMap WMS getMap (sf) WMS getMap (tiger) (sf) (tiger) multilayer 3 svg multilayer 3 svg Totale DB replicato Lat. media Throughput (ms) (rich/sec) 524 577 3,4943 3,4895 818 807 2,7626 2,7604 975 3,4847 1322 2,7477 2516 3,4379 2870 2,7571 1146 13,7263 1452 10,8429 Con chiamate relative a dati in differenti workspace la distribuzione mediante partizionamento risulta pi` efficiente u Federico Cacco – GeoServer nel Cloud 16/ 22
  • 17. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Partizionato VS Replicato - 1 workspace La distribuzione mediante replicazione ` pi` efficiente nel caso di richieste riferite sempre e u alla stessa workspace? Simulati 16 utenti contemporanei DB partizionato Lat. media Throughput (ms) (rich/sec) Richiesta WMS getMap WMS getMap (tiger) WMS getMap (tiger) WMS getMap (tiger) (tiger) multilayer 3 svg multilayer cql multilayer filter Totale DB replicato Lat. media Throughput (ms) (rich/sec) 634 3,2172 1021 2,6029 2972 3,1615 3227 2,5524 684 3,2058 925 2,5952 693 3,1974 989 2,5944 1248 12,5958 1542 10,1734 Distribuzione mediante partizionamento nuovamente pi` efficiente u Per piccole distribuzioni il middleware non introduce benefici Federico Cacco – GeoServer nel Cloud 17/ 22
  • 18. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Test sullo scaling up Lo scaling up riduce la latenza quando essa diventa eccessiva? Soglie scaling: Scaling up: lat. > 15 s (MAX) Latenza ridotta dallo scaling up Ritardo tra allarme ed effettiva diminuzione della latenza Federico Cacco – GeoServer nel Cloud 18/ 22
  • 19. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Test sullo scaling down Vengono liberate le risorse quando non sono pi` necessarie? u Soglie scaling: Scaling up: lat. > 15 s (MAX) Scaling down: lat. < 1 s (MED) Tempo attivazione istanza > Tempo disattivazione istanza Federico Cacco – GeoServer nel Cloud 19/ 22
  • 20. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Test sullo scaling down - oscillazione Importante utilizzare soglie di scaling corrette! Soglie scaling: Scaling up: lat. > 10 s (MAX) Scaling down 1: lat. < 1 s (MED) Scaling down 2: lat. < 0.6 s (MED) Oscillazione dovuta ad una soglia di scaling down troppo alta Federico Cacco – GeoServer nel Cloud 20/ 22
  • 21. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Conclusioni La latenza si rivela una buona metrica per determinare se il dimensionamento ` e coerente con il carico di lavoro Rendere l’architettura pi` affidabile mediante una sua distribuzione su pi` u u Availability Zone non ne pregiudica le prestazioni Nel caso di richieste fatte a pi` workspace, la distribuzione mediante u partizionamento si rileva pi` efficiente di quella realizzata mediante replicazione u Lo scaling up ` una operazione molto pi` onerosa, in termini di tempo e risorse, e u dello scaling down Difficile determinare soglie di scaling corrette Federico Cacco – GeoServer nel Cloud 21/ 22
  • 22. Scopo del progetto Approccio architetturale Caso d’uso Implementazione Test Conclusioni Sviluppi futuri Scomposizione servizi Predire i picchi di carico in modo da anticipare lo scaling dei servizi ⇒ Testare la distribuzione mediante replicazione con scaling up di dimensioni maggiori Federico Cacco – GeoServer nel Cloud 22/ 22