1.
Smart Cities and Communities and Social Innovation
Bando MIUR
D.D. 391/Ric. del 5 luglio 2012
Architettura e caratteristiche della PaaS di OCP - Sistema di monitoring IaaS e SaaS

2.
Che cosa ha fatto OCP in sintesi
Contesto attuale
 Servizi pensati e sviluppati in maniera
«destrutturata» e decisamente «localizzata»: un
server indipendente e un ambiente specifico per
ogni servizio
 In questo modo il più delle volte NON sono:
• interoperabili
• riutilizzabili
• migrabili (indipendentemente dalla piattaforma
utilizzata e dal sito erogatore)
Generano lock-in e alti costi per la gestione e
l’evoluzione
Piattaforma cloud aperta per la PA che offre:
 Sistema di gestione unitaria e ottimizzata di tutte le
risorse hardware di un CED -> riduzione dei costi
 Possibilità di attivazione automatica dei servizi
 Accesso ai servizi multi-dominio, Integrazione SPID,
Interoperabilità e composizione di servizi
 Migrabilità
Come è stato possibile raggiungere questi obiettivi:
 Sfruttando le potenzialità del «private cloud
aperto», basato su un Software Defined Data Center
con automazione e self service dei servizi
 Rendendolo facilmente collegabile con le maggiori
soluzioni «public cloud» esistenti (Hybrid Cloud),
per poter scalare e integrare risorse secondo
necessità
 Integrando prodotti open source secondo necessità

3.
Comune
Consumer
Comune
Consumer
Regione
Provider
Comune
Consumer
Comune
Consumer
Comune
Consumer
Comune
Consumer
Architettura di riferimento
L’architettura della piattaforma è stata
disegnata considerando:
• integrazione IaaS e PaaS
• scalabilità
• multilayer
• interoperabilità
• riuso delle componenti
• robustezza
Include al suo interno macro
componenti particolarmente rilevanti:
• modulo orchestrator/automation
• modulo monitoring/billing
• PaaS layer/services
• IaaS layer/services
• Open Data e Open Service Engine
• Application Store e Toolkit
Repository
• Citizen’s Marketplace

4.
La PaaS aperta nella piattaforma OCP
• Offre automazione sia per l’attivazione, che per la successiva gestione dei servizi su IaaS diverse a livello di
piattaforma
- offerta agli sviluppatori di un ambiente di sviluppo arricchito da numerosi “reusable components” offerti
as a service
- supporto allo sviluppo e debug di nuove applicazioni
• Elimina all’utente la necessità di gestire la complessità dei servizi infrastrutturali e delle configurazioni non solo
per lo IaaS di OpenStack
• L’utente/sviluppatore per attivare un servizio deve scrivere solo delle “ricette” che a breve supporteranno anche
lo standard internazionale TOSCA e potranno quindi essere utilizzate in qualsiasi infrastruttura cloud che
esponga l’interfaccia TOSCA
• Focus sulle soluzioni Open Source leader di mercato ma garanzia della massima apertura all’utilizzo in modo
trasparente di soluzioni cloud proprietarie ( es. VMware, Micorsoft Azure)

5.
Panoramica dell’architettura PaaS
• Workflow engine: JBPM 6.3
• Gestisce il ciclo di vita dei
servizi PaaS e IaaS
• Comunica con diverse soluzioni
cloud di middleware:
- Heat
- Cloudify
- Openshift
• Supporta il concetto di multi-
zona (es. installazioni differenti
e/o regioni di OpenStack)

6.
Comune
Consumer
Comune
Consumer
Regione
Provider
Comune
Consumer
Comune
Consumer
Comune
Consumer
Comune
Consumer
Requirement: possibilità per una PA di dotarsi di una piattaforma per l’erogazione di servizi secondo i paradigmi
tipici del Cloud astraendo ed integrando le diverse componenti dell’architettura per consentire l’orchestrazione di
processi complessi che coinvolgono elementi eterogenei.
OCP -> PaaS & IaaS Orchestrator Engine
OCP PaaS & IaaS Engine - Orchestratore di servizi e risorse
Standard (e consorzi di standardizzazione): input TOSCA (OASIS
consortium), interfacce HTTPS REST pubbliche (W3C), workflow
BPMN (OMG consortium).
Orchestratore: coordina i processi di erogazione dei servizi tra i
diversi componenti dell’architettura. Utilizza i workflow per gestire
le richieste dai layer superiori attuando opportune azioni sui singoli
moduli, astraendo e generalizzando i layer sottostanti.
Open/closed principle: oltre alle tecnologie Cloud «standard de
facto» supportate, si è aperti alle estensioni verso nuovi use-cases
(workflow) e/o prodotti (componenti) con una logica di sviluppo
modulare (plug-in) senza modifica del core open source esistente.

7.
Vantaggi della PaaS di OCP (1)
• Opensource
• Multitenancy
• Autenticazione, autorizzazione e auditing delle azioni
• Prodotti tecnologici si trasformano in servizi tecnologici con la logica «aaS»
• Servizi creati attraverso container Docker
• Facile integrazione di nuovi servizi containerizzati
• Storage ad oggetti autenticato e crittografato (segregazione della vista dati per singolo utente)
• Interfaccia user friendly rispetto alla IaaS
• API autenticate per integrazione con i servizi esposti

8.
• Le piattaforme PaaS selezionate e l’architettura disegnata consentono lo Scale up/down, scale out/in delle
risorse impegnate
• Un servizio scalabile garantisce:
- la resilienza alle failure
- incremento proporzionale delle prestazioni aumentando le risorse allocate in caso di necessità (aumento
n° sessioni, CPU oltre soglia…)
• Un’architettura software scalabile è indispensabile per trarre reale vantaggio da un’infrastruttura HW o
virtuale scalabile: la scalabilità è necessaria ad ogni livello della piattaforma
• L’utilizzo dei servizi di load-balancing + autoscaling offerti dagli strati IaaS e PaaS è una combinazione
vincente per implementare sistemi fault-tolerant, scalabili e ad alte prestazioni.
Vantaggi della PaaS di OCP (2) – Elasticità e alta affidabilità

9.
Migrare servizi/applicazioni già
esistenti nel cloud:
es. Creazione VM da immagini
disco
Prototipare, sviluppare ed eseguire
applicazioni nativamente in cloud:
es. Combinando componenti a
servizio (Database, Business
Intelligence, etc)
Iniziare ad adottare servizi cloud:
Creazione VM (e altri servizi IaaS) e
configurazione manuale
Cloud Shift Cloud Native
Vantaggi per gli sviluppatori e integrazioni
Cloud Porting

10.
Vantaggi per gli sviluppatori e integrazioni
API REST (rispetto allo standard SOAP è molto più leggero, scalabile, performante)

11.
I servizi tecnologici disponibili “as a service”
• Console di gestione della piattaforma (anche IaaS)
• Servizi di autenticazione, autorizzazione, auditing integrati
• Servizi di monitoraggio e metering delle applicazioni
• Servizi di Database (DBaaS)
• Servizi di Business Process Management (BPMaaS)
• Servizi di Business Intelligence (BIaaS)
• Servizi per l’esecuzione delle applicazioni (APPaaS)
• Servizi di messaggistica (SMSaaS, EmailaaS)
• Servizi di Message Brokering (MQaaS)
• Servizi di Certification Authority (CAaaS)
• Servizi per l’ottimizzazione della Quality of Service
• Servizi per la realizzazione di Application Store

12.
Strumenti utilizzati

13.
Bursting su Cloud pubblico con integrazione AWS e servizi per la PA

14.
Smart Cities and Communities and Social Innovation
Bando MIUR
D.D. 391/Ric. del 5 luglio 2012
Monitoring IaaS e PaaS di OCP

15.
Architettura Monitoring IaaS/PaaS
15
Openstack
Zabbix Proxies
IaaS ProxyMetrics ProxyWatcher Proxy
Monitoring Pillar
Zabbix Servers
IaaS ServerMetrics ServerWatcher Server
PaaS
Zabbix wrapper
Creazione
Monitoraggio
metriche e stato
Layer di monitoraggio
che si interfaccia con
i server zabbix.
Software per
monitoring e metering.
Tutte le informazioni
vengono memorizate in
questi server
Server intermedio
da tra le VM e i
server Zabbix
Livello infrastutturale,
ospita le macchine virtuali
creati tramite PaaS.
Gli agent zabbix a bordo
delle macchine
comunicano lo stato dei
servizi.

16.
Funzionalità Monitoring IaaS/PaaS
Controllo e gestione dell’intera piattaforma cloud:
 Livello IaaS
- Utilizzo di risorse delle macchine istanziate (CPU, Disco, Memoria, Reti, etc.)
- Stato servizi VM (Avviata, Spenta, In errore)
- Dati utilizzabili per effettuare billing
 Livello PaaS
- Stato componenti dei servizi PaaS (In funzione, In errore)
- Dati utilizzabili per effettuare billing

17.
Metriche Macchina Virtuale
Raccolta di metriche delle VM presenti sulla PaaS (CPU, Ram, Disco, Network)

18.
Esempio Monitoring PaaS – Stato Avviato
Monitoraggio del servizio MySQL a bordo della macchina. Stato Avviato

19.
Esempio Monitoring PaaS – Stato Avviato
Monitoraggio del servizio MySQL a bordo della macchina. Stato Avviato. Gli agent zabbix mandano informazioni
relativi al servizio MySQL presente a bordo della macchina virtuale, i server zabbix memorizzano lo stato del servizio
e la PaaS aggiorna lo stato come avviato.

20.
Esempio Monitoring PaaS – Stato Errore
Monitoraggio del servizio MySQL a bordo della macchina. Stato in errore.

21.
Esempio Monitoring PaaS – Stato Errore
Monitoraggio del servizio MySQL a bordo della macchina. Stato in errore. Il servizio a bordo della macchina non
funziona, gli agent di zabbix hanno comunicato ai server che il servizio non è funzionate; la PaaS viene aggiornata di
conseguenza.

22.
Comune
Consumer
Comune
Consumer
Regione
Provider
Comune
Consumer
Comune
Consumer
Comune
Consumer
Comune
Consumer
• Sito ufficiale di OpenCity Platform: http://www.opencityplatform.eu
• OCP platform: https://infncloud.ponsmartcities-prisma.it
• OCP platform support: https://support.ba.infn.it/redmine/projects/supporto-ocp
• OCP tutorial: https://agenda.cnaf.infn.it/conferenceTimeTable.py?confId=738#20150930
• Contatti: http://www.opencityplatform.eu/contatti
Riferimenti