Il webinar presenterà la cloud federata GARR e i servizi che offre alla comunità dell’università e della ricerca. Il seminario sarà l’occasione per illustrare concretamente come ottenere ed utilizzare i servizi e in che modo le organizzazioni che fanno parte della comunità GARR possano partecipare mettendo in comune le proprie risorse. Il servizio di Cloud Computing federato realizzato da GARR è disponibile da qualche settimana all'indirizzo cloud.garr.it. ed è stato sviluppato per rispondere alle esigenze della comunità della ricerca e dell’istruzione emerse nel corso di una consultazione pubblica condotta nei mesi scorsi. Attualmente sono disponibili servizi IaaS (Macchine Virtuali e Virtual Datacenter) e PaaS (self-service deployment di applicazioni cloud). Con il servizio di Virtual Datacenter un’organizzazione può ottenere una determinata quantità di risorse di calcolo e storage da gestire in autonomia,suddividendole tra progetti e assegnandole ai propri utenti, esattamente come se disponesse di una propria infrastruttura cloud. Il servizio di self-service deployment, permette agli utenti di installare pacchetti che compongono applicazioni cloud complete.Ad esempio, il pacchetto “Moodle in the Cloud”, consente con un click di installare in modo automatico tutto quanto serve per mettere in esercizio sul cloud un sito di e-learning basato su Moodle. Circa 200 pacchetti sono già disponibili ed altri possono essere sviluppati e condivisi da GARR stesso o dalla comunità di utilizzatori, a supporto di attività di formazione e scientifica, ad esempio per la realizzazione di laboratori didattici o progetti di ricerca. La piattaforma e i servizi sono basati su tecnologie open source e in particolare su OpenStack, la piattaforma cloud più diffusa e sostenuta da una comunità di oltre 40.000 sviluppatori. Le macchine virtuali possono utilizzare sistemi operativi sia Linux che Windows. Una specificità della cloud GARR è la sua architettura federata, aperta alla partecipazione da parte di gruppi o istituzioni, che possono attivare una regione della cloud e mettere a disposizione le proprie risorse attraverso un’operazione semplice e guidata. Questo approccio vuole favorire la nascita di una comunità di utenti e specialisti che condividano esperienze nell'ambito del cloud computing.

1. Una Cloud Federata per l’Università e la
Ricerca: come usarla, come partecipare
Giuseppe Attardi
Dipartimento CSD
Consortium GARR

2. Sommario
 Motivazioni e obiettivi
 Architettura
 Come Usarla
 Come Partecipare
 Stato

3. Sommario
 Motivazioni e obiettivi
 Architettura
 Come Usarla
 Come Partecipare
 Stato
Da utente finale

4. Sommario
 Motivazioni e obiettivi
 Architettura
 Come Usarla
 Come Partecipare
 Stato
Da utente finale
Da amministratore di sistemi

5. A volte ritornano
 Chi ha introdotto le Macchine Virtuali?
 VMWare
 Citrix
 IBM

6. A volte ritornano
 Chi ha introdotto le Macchine Virtuali?
 VMWare
 Citrix
 IBM
1999

7. A volte ritornano
 Chi ha introdotto le Macchine Virtuali?
 VMWare
 Citrix
 IBM
1999
2003

8. A volte ritornano
 Chi ha introdotto le Macchine Virtuali?
 VMWare
 Citrix
 IBM
1999
1968
2003

9. VM su Mainframe superate dai PC, superati ...
VM su
Mainframe:
tante persone
su una
macchina
PC: una intera
macchina a
persona
VM su PC:
SO diversi su
stessa
macchina
Virtualization:
tante
macchine su
un PC
IaaS: tante VM su
tanti PC

10. VM su Mainframe superate dai PC, superati ...
VM su
Mainframe:
tante persone
su una
macchina
PC: una intera
macchina a
persona
VM su PC:
SO diversi su
stessa
macchina
Virtualization:
tante
macchine su
un PC
IaaS: tante VM su
tanti PC

11. VM su Mainframe superate dai PC, superati ...
VM su
Mainframe:
tante persone
su una
macchina
PC: una intera
macchina a
persona
VM su PC:
SO diversi su
stessa
macchina
Virtualization:
tante
macchine su
un PC
IaaS: tante VM su
tanti PC

12. VM su Mainframe superate dai PC, superati ...
VM su
Mainframe:
tante persone
su una
macchina
PC: una intera
macchina a
persona
VM su PC:
SO diversi su
stessa
macchina
Virtualization:
tante
macchine su
un PC
IaaS: tante VM su
tanti PC

13. VM su Mainframe superate dai PC, superati ...
VM su
Mainframe:
tante persone
su una
macchina
PC: una intera
macchina a
persona
VM su PC:
SO diversi su
stessa
macchina
Virtualization:
tante
macchine su
un PC
IaaS: tante VM su
tanti PC

14. VM su Mainframe superate dai PC, superati ...
VM su
Mainframe:
tante persone
su una
macchina
PC: una intera
macchina a
persona
VM su PC:
SO diversi su
stessa
macchina
Virtualization:
tante
macchine su
un PC
IaaS: tante VM su
tanti PC

15. Ibrido è meglio

16. Ibrido è meglio

17. IaaS: Infrastructure as a Service
Ma non basta

18. IaaS: Infrastructure as a Service
Automatizzare il
sollevamento pesi

19. IaaS: Infrastructure as a Service
Orchestrare la
composizione di sistemi

20. Ma prima …

21. Ma prima …
Ci interessa?

22. Ma prima …
Ci interessa?
Vogliamo lavorarci?

23. Questionario su Servizi Cloud: giugno 2016
 Oltre 200 risposte dalle Università
 Esigenza diffusa di servizi cloud orientati alla
ricerca
 Interesse per servizi managed (non solo VM)
 es. >90 richieste di servizi PaaS per Big Data
analysis
 Ampia disponibilità a contribuire a una Cloud
Federata, contribuendo
 risorse (~50 risposte)
 lavoro
 sviluppo di servizi

24. Tratteniamo le
Nuvole

25. Come
 Progetto di Cloud Federata, con la
partecipazione di esperti
 Ogni membro della federazione rende
disponibili risorse:
 Gestite congiuntamente con strumenti
automatizzati
 Riducendo il carico di ammistrazione
 Utenti:
 attivano in self-service applicazioni pronte per
l’uso

26. Infrastruttura GARR-X Progress

27. Obiettivi della Cloud Federata
 Facilitare la transizione verso il cloud
computing, svolgendo un ruolo attivo
 Condividere risorse, pur mantendone il
possesso
 Scambiarsi best practices su gestione e utilizzo
 Evolvere verso l’uso di applicazioni cloud
native
 Coinvolgere la comunità GARR nel costruire un
catalogo di applicazioni cloud

28. Federated Cloud Architecture
Università A
Istituto del CNR
Università B
INAF
Utenti globali:
possono accedere a
qualunque risorsa

29. Service Architecture
Advanced
Container
Technology

30. Open Stack
 Piattaforma di Cloud Computing ampiamente
diffusa e supportata
 Oltre 45.000 sviluppatori in tutto il mondo
 Complesso da gestire
 Confezionata una versione di riferimento:
 Descritta in modo dichiarativo
 Facilmente configurabile e replicabile
 Gestita con strumenti di orchestrazione

31. GARR Reference Architecture: OpenStack

32. Automazione delle Installazioni
 Basata su strumenti Open Source che
semplificano l’installazione di:
 Piattaforme cloud (es. OpenStack, Kubernetes) e
 Applicazioni cloud (e.g. Data Analytics)
 sia su:
 propria regione cloud federata
 cloud pubblica
 in pochi semplici passi

33. Come Usarla: IaaS

34. GARR Cloud Services

35. Passi di abilitazione
 Prerequisito: disporre di un’identità su:
 Federazione IDEM
 Open ID Connect (Google)
 Invio richiesta di creazione account:
 cloud.garr.it/forms/register
 Amministratore di dominio autorizza
 Mail di conferma al richiedente
 Accesso abilitato su:
 dashboard.cloud.garr.it
❌

36. Big Data Analytics: One Click Deployment

37. PaaS: Platform as a Service
Costruisci ciò che ti serve

38. PaaS: Platform as a Service
Assembla il resto

39. PaaS: Platform as a Service
PaaS non basta

40. PaaS: Platform as a Service
Docker container aiutano

41. Vogliamo cose che funzionano e basta
 Self Service
 Componibili
 Sviluppo Iterativo Veloce
 Erogazione Rapida
 Tolleranti ai Guasti
 High Availability

42. Applicazioni Cloud
 Dichiarative
 Componibili
 Massima Agilità
 Astrazione da infrastruttura e servizi
 Multiple modalità di erogazione

43. Dichiarativo
 App A richiede:
 X memoria e Y CPU
 N storage
 Parlare con B e C
 URL di contatto
 Girare in loco, vicino a B A
CB

44. Funzionalità necessarie
 Cosa richiede App A
 Dove gira A
 Come App A trova B e C
 Che succede col carico
 Che succede coi guasti

45. Funzionalità necessarie
 Cosa richiede App A
 Packaging e dipendenze
 Dove gira A
 Provisioning e Scheduling
 Come App A trova B e C
 Indirizzamento e scoperta
 Che succede col carico
 Scaling e bilanciamento automatico
 Che succede coi guasti
 Monitoraggio e rilancio

46. Abbiamo pezzi della soluzione
 Isolamento delle parti (Container)
 SDS – Software Defined Storage
 SDN – Software Defined Networking
 Management and Resource Pooling
 Machine Learning for load prediction
 Dynamic allocation and rebalancing

48. Vedremo quanto

49. La soluzione è prossima
Vedremo quanto

50. La soluzione è prossima
Vedremo quanto

51. Come Usarla: Self-Service
Deployment

52. Deployment bundle Moodle

53. Federazione Cloud Esterne: Caso Amazon
$ ssh -i aws.pem ubuntu@90.147.166.80
$ juju clouds
Cloud Regions Default Type Description
aws 12 us-east-1 ec2 Amazon Web Services
aws-china 1 cn-north-1 ec2 Amazon China
aws-gov 1 us-gov-west-1 ec2 Amazon (USA Government)
azure 18 centralus azure Microsoft Azure
azure-china 2 chinaeast azure Microsoft Azure China
cloudsigma 5 hnl cloudsigma CloudSigma Cloud
google 4 us-east1 gce Google Cloud Platform
$ juju deploy ~/mediawiki-single
$ juju status
Model Controller Cloud/Region Version
default aws-us-east-1 aws/us-east-1 2.0.2
App Version Status Scale Charm Store Rev OS Notes
mediawiki unknown 1 mediawiki jujucharms 3 ubuntu exposed
mysql waiting 0 mysql jujucharms 29 ubuntu
Unit Workload Agent Machine Public address Ports Message
mediawiki/1* unknown idle 2 54.161.6.44
Machine State DNS Inst id Series AZ
2 started 54.161.6.44 i-02d632e9b1d7b8507 trusty us-east-1a
Accesso al
controller Juju
Cloud disponibili
Appicazione MediaWiki

54. MediaWiki Deployed on AWS: Juju view

55. MediaWiki Deployed on AWS: AWS

56. Come Partecipare

57. Comunità
 Creare comunità di utenti e sviluppatori
 Costruire Catalogo di servizi condivisi
 Esempi:
 Laboratori didattici
 Moodle as a Service

58. Passi da eseguire
 Prerequisiti: disporre di server x86 con IPMI
 Installare MAAS
 Assegnare server a MAAS (tramite MAC)
 Installare Juju
 Installare OpenStack tramite bundle Juju
 Collegare regione cloud con federazione
 Dettagli su:
 https://cloud.garr.it/doc/federation/

59. Attivazione Federazione

60. OpenStack Automated Deployment

61. Stato

62. Servizi Attivi
 VM
 macchine virtuali classiche
 Virtual Datacenter
 gruppi di risorse autogestite
 PaaS
 Self provisioning of ready to use application
packages
• (WordPress, IdP, Moodle, Spark, ML, ecc.)

63. Situazione
 In produzione da 3 mesi
 Apparati e piattaforma sotto contratti di manutenzione
 Supporto utenti (comprese soluzioni speciali)
 Garanzie
 Continuità del servizio
 Sicurezza dei dati
 Oltre 200 utenti in prova
 Una dozzina di VDC
 Rilascio continuo di nuove funzionalità:
 Deployment su cloud esterne (Amazon, Google)
 Container platform
 Potenziamento di hardware e storage
 Attivazione di convenzioni con enti da marzo

64. Quanto costa?
 I prezzi sono calcolati sui costi in funzione
della sostenibilità del servizio
 Più utenti, minori i costi
 Attualmente con l’ipotesi di uso delle risorse
al 30%, prezzi in linea con analoghi servizi
commerciali
 Con numeri più elevati, prezzi calano
 Costi calcolati a consumo e a consuntivo
 Risorse contribuite alla federazione non
soggette a costi

65. Conclusioni
 GARR Federated Cloud è un servizio per la
comunità GARR
 Consente di condividere risorse e competenze
 Erogazione e gestione automatizzate
 Coinvolgimento della comunità nello sviluppo di
applicativi PaaS specifici per ricerca e
formazione
 Partecipare attivamente alla transizione verso
il Cloud Computing

66. Ragionamenti sui prezzi
 AWS ha un margine operativo di 30%
 Margini su cloud privata: 0
 Servizi si pagano: OPEX
 Infrastructure si ammortizza: CAPEX
 CAPEX possono essere condivisi, OPEX no
 CAPEX restano, OPEX si consumano
 Benefici di outsourcing costi IT si ottengono
anche con la federazione
 Benefici di economia di scala ottenibili
acquistando infrastrutture cloud, non servizi
cloud

67. Domande