Smart Cities and Communities and Social Innovation Bando MIUR D.D. 391/Ric. del 5 luglio 2012 “Open City Platform: PaaS architecture” Dante Bonino OCP architectural group member – Santer Reply

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 2 Authentication - Authorization - accounting adapter Disaster Recovery as a Service (DRaaS) Real Environment (VM infrastructure, HW, network) IaaS / PaaS Management Flexible Resource Management Cloud to Cloud (C2C) Cloud to Ground (C2G) Service Composition Orchestrator brokering Queue system Openstack Native API Recipe (HEAT/TOSCA) API Lifecycle Engine API Monitoring engine PaaS layer API Cloud Formation as a Service (CFaaS) Billing engine App store Citizen's Marketplace App Management Portal App API PRISMA Interface TOSCA enabled iPaaS Layer API mysql Postgres SQL RDF Open Data Services RC Open Data Services RC Opendata from external source Open data engine Appserver IAAS providers Authentication - Authorization - accounting API Open Data Layer L’architettura generale della Piattaforma OCP Reusable components (REST services) Reusable components (REST services)

I servizi PaaS di basso livello di OCP Identity access management Database Application deployment Queue system Business intelligence Business Process Manager Open Data framework Tecnologie offerte as a Service derivati da PRISMA OCP offre già servizi di tipologia PaaS progettati per essere erogati rispettando concetti chiave del Cloud Computing: Monitoraggio Raccolta metriche - Billing Elasticità Scalabilità Self service Affidabilità Restful access Ognuno di questi elementi è parte fondante della piattaforma Messaging (mail + sms) 3

Le Piattaforme PaaS di OCP API OCP ha scelto di integrare due diverse piattaforme leader di mercato: Cloudify e Openshift Entrambe le piattaforme sono Openstack enabled E’ stato scelto di far coesistere nella PaaS di OCP Cloudify e OPENSHIFT per risolvere problemi diversi. Entrambe le piattaforme si basano su ricette/cartridge. Cloudify si configura come orchestrator tecnologico avanzato di configurazioni complesse, sia basate su VM che dockers Openshift offre agli sviluppatori un environment arricchito da numerosi “reusable components” costruiti in OCP per grantire un alta percentuale di riuso di componenti comuni Lo strato di integrazione e l’orchestrator OCP giocano un ruolo fondamentale nella gestione delle diverse piattaforme e delle ricette relative ai servizi erogati. Tale strato è esposto attraverso una RESTful interface e sarà standardizzato tramite TOSCA

Open Source Platform per il Deploying, Managing e Scaling di Applicazioni Complesse Multi-Tier su un cloud Cloudify consente di eseguire una Applicazione su diverse tipologie di infrastruttura Cloud senza alcun cambiamento del codice, e permette di usare un eventuale tool di automation e configuration management di propria scelta. Cloudify – Cosa è Rif.

Applicazione: è un insieme di servizi. Es. «AlfrescoLB» Servizio è un insieme di istanze di servizio che rappresentano un application tier. Es. un application tier può essere: un web container, un database, un cluster di istanze di servizi Tomcat, etc…. Ogni istanza di servizio risiede su un host (tipicamente una VM). Cloudify 2.7 – Applicazione e servizi servizio applicazione

Cloudify 2.7 – Come funziona Quello che serve per il deploy di una applicazione… -un Cloud Driver, un file di configurazione che contiene le informazioni necessarie per poter utilizzare i servizi di una infrastruttura cloud (es. OpenStack) -una Ricetta (aka blueprint), uno script che descrive il piano di deploy e gestione automatizzata dei servizi che compongono l’applicazione Rif.

Cloudify 2.7 – Cloud Driver Rif. Esempio di Cloud Driver: credenziali del cloud, flavor, image

Cloudify 2.7 – Ricetta applicazione e ricetta servizio Service Instance Events Rif Una ricetta di servizio descrive:  servizi da eseguire (es. tomcat)  come installare e configurare i servizi  da dove scaricare l’applicazione o il codice sorgente  quando aggiungere o rimuovere le istanze del servizio, e quante istanze per volta aggiungere/rimuovere  come monitorare ogni servizio

Cloudify 2.7 – Deploy “single-click” di una applicazione Bootstrap process SSH Rif. Si fa notare che Cloudify è in grado di usare immagine completamente vuote (solo Sistema Operativo), ed istalla tutto il necessario a runtime. Infrastruttura cloud Application deploying REST SS H Single-click! Servizio REST: porta 8100 Infrastruttura cloud Cloudify è in grado di usare immagini completamente vuote (solo Sistema Operativo), ed installa tutto il necessario (JVM, CFY agent, esecuzione di comandi custom) subito dopo la creazione della VM (JVM, CFY agent di MNG, esecuzione di comandi custom) La Management VM mantiene in RAM le informazioni sulle applicazioni deployate.

Cloudify Monitoring Management Dashboard: porta 8099 Rif. Una volta che il deploy è completato, Cloudify monitora continuamente l’applicazione utilizzando sia metriche built-in che metriche custom definite dall’utente. Le metriche possono essere visualizzate nella Cloudify Management Dashboard o interrogate mediante le REST API. E’ possibile installare agent di monitoraggio custom (es. zabbix) durante il processo di installazione dell’applicazione.

Cloudify 2.7 – Auto-healing Rif. La funzionalità di auto-healing di Cloudify consente di ottenere il massimo dalla tecnologia cloud mantenendo l’applicazione sempre funzionante senza alcun intervento manuale. Cloudify risana le VMs perse o i servizi in crash e riconfigura automaticamente l’applicazione. In particolare, quando la Management VM si accorge di un failure sia della Application VM che di un servizio in essa installato e monitorato, rispettivamente ricrea la Application VM (e riesegue la ricetta) oppure riesegue soltanto la ricetta.

Cloudify 2.7 – Upgrade Cloudify supporta gli upgrade post-deployment. Possono essere definiti dei custom commands, invocati manualmente o programmaticamente, che definiscono, ad esempio, come acquisire una nuova versione del codice e come deployarlo nella VM che ospita il relativo servizio. Rif.

Cloudify 2.7 – Auto-scaling Cloudify scala automaticamente l’applicazione utilizzando le policies custom definite dall’utente. In particolare verranno confrontate le scaling rules definite dall’utente con le metriche misurate. Quando il Cloudify Orchestrator rileva una violazione dello SLA usando le scaling rules custom, invoca un workflow di scale-out che crea nodi aggiuntivi e li aggiunge ad un eventuale load balancer. Rif.

Le piattaforme PaaS selezionate e l’architettura disegnata consentono lo Scale up, scale down, scale out, scale in delle risorse impegnate Un servizio “scalabile” garantisce: incremento proporzionale delle prestazioni aumentando le risorse allocate in caso di necessità (aumento n° sessioni, CPU oltre soglia…); la resilienza alle failure; 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, ad alte prestazioni. Scalabilità ed alta affidabilità

«Gli sviluppi chiave di OCP garantiscono l’interoperabilità tra varie soluzioni e il carattere di interregionalità, l’approccio della sperimentazione in testbed e sul campo consente di testarli in concreto» An integration platform as a service (iPaaS) is a form of platform as a service (PaaS... ) that provides capabilities to enable subscribers (usually referred to as "tenants") to implement integration projects involving any combination of cloud- resident and on-premises endpoints — data sources, applications, services (in the service-oriented architecture [SOA] sense of the word), APIs and processes. This is achieved by leveraging the iPaaS capabilities to develop, deploy, execute, manage and monitor integration flows (at times also referred to as "integration interfaces") linking multiple endpoints..... IaaS + PaaS + SaaS = iPaaS Le possibilità di integrazione Cloud to Cloud (C2C) e Cloud to Ground (C2G) a supporto e a garanzia della interoperabilità interregionale sono molte ma quali sono le funzionalità che primariamente interessano ? La fase di acquisizione dei requisiti con le PAL coinvolte (Regione Emilia Romagna, Regione Marche e Regione Toscana) si sta rivelando determinante per agevolare la definizione di specifici casi d’uso.

iPaaS: la vera integrazione tra servizi eterogenei Caso d’uso 1: iPaaS Puro Esposizione di un servizio che abbia come origine l’output di servizi erogati da differenti PaaS/IaaS. Caso d’uso 2: Cloud Bursting L’IPaaS è in grado di utilizzare differenti strati IaaS: Ec2 + OpenStack., In caso di maggior richiesta di risorse possono essere utilizzate risorse appartenenti a cloud diversi, pubblici o privati utilizzando l'intelligenza dell’orchestrator ed il modulo di brokering Caso d’uso 3:PaaS Scaling L’IPaaS è in grado di utilizzare differenti strati PaaS,Il provisioning delle piattaforme può essere effettuato per qualunque tipo di cartridge: Piattaforma intera (ad esempio Alfresco) o singole componenti (SQLServer, Tomcat, Apache, etc.) IPaas

PaaS layer attuale Platform UI Layer REST API Native API Thymeleaf, spring-mvc spring-security (SSO authentication with SAML) Thymeleaf, spring-mvc spring-security (SSO authentication with SAML) IaaS Layer DB Native API Adapter (IaaS) Openstack4j DAO Recipe (HEAT) Native API ORCHESTRATOR ENGINE Monitoring Connector Cloudify Connector Openshift Connector Native API Monitoring Pillar Native API HOT & Receipe Repository HOT & Receipe Repository Native API

Basato sul workflow engine: JBPM 6.1JBPM 6.1 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 (i.e. installazioni differenti e/o regioni di OpenStack) PaaS layer attuale

API REST-ful per gestire il ciclo di vita sei servizi: Application as a Service (Tomcat, Jboss…) Business Intelligence as a Service (Penthao), Database as a Service (MySQL, PostgreSQL), Message Queue as a Service (RabbitMQ) VMaaS Utilizzo dei “verbi” HTTP e degli codici di stato standard: GET: visualizzare lo stato dei servizi PUT: creare un servizio DELETE: cancellaarea servizio POST: start, stop and restart di un servizio Sicurezza basata su token di accesso Modello RBAC {... "zoneId":2, "serviceDetails":{ "name":"prisma-example", "domainName":"prisma-ex.prismacloud.it", "loadBalancingInstances":0, "publicVisibility":false,... "environment":{ "availabilityZone":"nova", "iaaSFlavor":"medium", "qos":"silver" } }, "vmDetails":{ "volume":0, "networks":[2,3], "imageId":3... } Prisma Orchestrator – REST APIs

Validazione degli Input Verifica dei permessi Verifica stato infrastruttura Verifica disponibilità delle risorse Crea servizio Scelta adapter: Heat Cloudify Openshift Monitora il servizio Aggiungi il servizio al sistema di monitoraggio Verifica che il servizio sia monitorato e pronto Prisma Orchestrator – JBPM

22 Prisma Orchestrator – JBPM, validazione degli input

23 Prisma Orchestrator – JBPM, creazione del servizio

24 Prisma Orchestrator – JBPM, monitoraggio del servizio

Prisma Data Access Layer Il database di piattaforma è MySQL Le query sono scritte utilizzando la sintassi di Mysema Querydsl. Il framework Querydsl fornisce allo sviluppatore un metodo type-safe per scrivere le query in Java. JPA mappa le tabelle del database in oggetti Java (Entity) L’implementazione JPA utilizzata è Hibernate La consistenza delle transazioni è garantita da JTA 25