Open City Platform, Agenda Digitale Locale, Riccione 18 settembre 2014
OCP-Architettura e caratteristiche della PaaS
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
Dante Bonino – Senior Cloud Architect (Reply S.p.A.)
d.bonino@reply.eu
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à
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
14. Smart Cities and Communities and Social Innovation
Bando MIUR
D.D. 391/Ric. del 5 luglio 2012
Monitoring IaaS e PaaS di OCP
Dante Bonino – Senior Cloud Architect (Relpy S.p.A.)
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
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.
Openstack è installato in modalità monoregione o multiregione. Uno IaaSEnvironment per OCP è un Openstack declinato su una specifica regione. Un Openstack declinato su una specifica regione è visto da OCP con il concetto di zona. L’installazione di OCP può supportare zone multiple. Openstack partiziona le risorse in project che in OCP facciamo corrispondere al concetto di Workgroup nella specifica zona.
L’ orchestratore è il componente core della piattaforma OCP ed è in grado di far interagire i diversi elementi dell’architettura.
L’OCP platform engine espone un’interfaccia REST TOSCA compliant in grado di riceve dal Portale di Managment, dall’ AppStore o direttamente tramite client REST le differenti richieste di creazione e gestione del ciclo di vita dei servizi erogati dalla PA.
TOSCA è lo standard de facto che si pone l’obiettivo di migliorare la portabilità e la gestione di applicazioni e servizi cloud in tutto il loro ciclo di vita garantendo l’iteroperabilità delle applicazioni dall’infrastruttura cloud che le andrà ad ospitare.
Inoltre, l’orchestrator aggiunge l’intelligenza necessaria per comprendere come e dove creare le applicazioni e quindi scegliere a quale componente dello strato sottostante delegare l’erogazione del servizio rendendo le richieste TOSCA compatibili con i diversi PaaS e IaaS provider.
E’ importante sottolineare che le tecnologie dei layer sottostanti rappresentano i best of breed del mercato attuale e, in qualche modo, come Openstack, stanno diventando standard de facto.