OR 1 & OR 2 Stato e piano attività Cristina Aiftimiei (INFN-CNAF) CTS - Bologna - 28/07/2016

OR 1 Analisi delle soluzioni e sinergie con progetti esistenti per favorire il riuso delle componenti open-source e la definizione della governance di una Smart City AR1.1 - “Analisi dello stato dell'arte sulla normativa, tecnologia, interoperabilità e standard” AR1.2 - “Analisi esigenze e requisiti di dominio per le PAL” AR1.3 - “Studio e definizione di un modello organizzativo di riferimento basato sul cloud per l’erogazione di servizi applicativi” AR1.4 - “Studio e definizione del modello architetturale di riferimento”

OR 1 Analisi delle soluzioni e sinergie con progetti esistenti per favorire il riuso delle componenti open-source e la definizione della governance di una Smart City Era: AR1.1-M11, AR1.2 – M11, AR1.3 – M4-M15, AR1.4 – M15

SAL OR 1 Mancanto contributi Reply

OR 2 Metodi e strumenti per gestione cloud AR2.1 – M3 - M29; AR2.2: M3 – M29, AR2.3: M3 – M29; AR2.4: M3 – M29; R2.5: M8 – M30 Pianificare e realizzare uno strato di mediazione tra le infrastrutture IaaS attraverso le quali OCP recupererà risorse di rete, calcolo e storage e i livelli OCP superiori. Cloud Management Interface Monitoring as a Service (MaaS) Cloud Formation as a Service (CFaaS) Disaster Recovery as a Service (DRaaS)

AR 2.1 “Definizione ed implementazione di una interfaccia di cloud management” Attivita’ di tipo Ricerca Industriale, M3 – M41 (M29) Lead: INFN 11 pm - Partner: Santer Reply 20 pm, Almaviva 3 pm Interfaccia di gestione dell’infrastruttura di livello IaaS, per sfruttare funzionalità evolute (orchestrazione, failure tolerance, load balancing, elasticity, etc) federazione di risorse anche eterogenee accesso tramite interfacce semplificate per nascondere la complessità Modifiche – non ci sono Attivita’: Passate delineata l'architettura In particolare, è emersa la necessità di un layer intermedio fra lo strato IaaS e lo strato PaaS che possa fare da "interfaccia unica" fra l'insieme eterogeneo di provider di risorse di infrastruttura e la gestione di quelle di piattaforma. la maggior parte delle risorse concentrata sullo sviluppo di un'interfaccia che utilizzi le API REST deciso di mantenere anche l'utilizzo del maggior numero di interfacce possibile (OCCI, CDMI, EC2). OCCI deprecato -> Introdotto l’utilizzo di template TOSCA (OASIS Topology and Orchestration Specification for Cloud Applications) Futuro interfaccia - non c’è molto da aggiornare - l’attività dipende da come Reply vuole interfacciarsi sulla IaaS, riportando alcuni sviluppi Prossimamente - sentirsi con Reply per la definizione di una roadmap L’Orchestratore dovrebbe già suppotare TOSCA => da Sett. Capire come integrare queste funzionalità in OCP

AR 2.2 “Studio di metodologie e parametri per il monitoring di IaaS e PaaS” Attivita’ di tipo Ricerca Industriale, M3 – M29 Lead: INFN 41 pm - Partner: Santer Reply 14 pm, Almaviva 12 pm svilupperà la componente architetturale relativa al “Monitoring & metering” Definizione architetturale Implementazione degli Admin Monitor di Livello I Definizione ed implementazione del MaaS (Monitoring-as-a-Service) Billing Modifiche: infrastruttura di monitoraggio federata fornire al contempo il backend di monitoraggio a risorse cloud federate che non siano dotate di un backend proprio. Implementazione del servizio di Monitoraggio (invece di Admin Monitor di Livello 1) Attività: sperimentazione, tunning, fixing per il prototipo attuale Il secondo protottipo: migliore integrazione con la parte sicurezza, deployment affidabile attivita' di automatizzazione installazione di tutto il pacchetto monitoring e monitoring pilar Incontro tecnico (Cherici, Guarise, Grandolfo) per chiarire alcuni aspetti che riguardano le metriche che verrano rese disponibili nel mon monitoring SaaS. Serve un testbed con ceilometer funzionante Installazione del “componente” Monitoring nelle regioni Tutti i partner coinvolti fanno presente i livelli bassi di effort da destinare nell’ultimo anno

AR 2.3 “Studio di modelli e strumenti per il dispiegamento di applicazioni e servizi in cluster” Attivita’ di tipo Ricerca Industriale, M3 – M29 Lead: INFN 55 pm - Partner: Santer Reply 16 pm Studio e la progettazione di un servizio di deployment di cluster in modo da consentire il dispiegamento di gruppi di risorse connesse in rete, in maniera semplice e configurabile (alla AWS CloudFormation/HEAT OpenStack, JuJu Ubuntu, etc) Modifiche: studio e la progettazione di una serie di tool per l’installazione e la configurazione automatica dello strato IaaS, unito ad un servizio di deployment di cluster in modo da consentire il dispiegamento di gruppi di risorse per lo strato PaaS. L’obiettivo di questa attività è quello di fornire strumenti e servizi per la gestione semplice e facilitata degli strati IaaS e PaaS in modo da soddisfare la maggior parte delle esigenze di una PAL mantenendo la creazione, modifica e distruzione dei cluster semplice da gestire. Attività: Pregresse Scouting PaaS – scelta Cloudify & Open Shift Valutazione Heat, jClouds, TOSCA Future Allineamento tool alla release Mitaka Definizione procedura upgrade (semi-automatica)

AR 2.4 “Studio di metodologie e sviluppo di strumenti per il consolidamento ed il disaster recovery di cloud distribuite” Attivita’ di tipo Ricerca Industriale, M3 – M41 (M29) Lead: INFN 7 (11) pm - Partner: Santer Reply 16 (20) pm, Almaviva 11 (3) pm Avanzamento rispetto allo stato dell’arte delle funzionalità di Disater Recovery presenti nelle infrastrutture di livello IaaS Studio dei vari scenari e quindi livelli di Disaster Recovery necessari Anche in relazione alle diverse tipologie di siti e servizi che sono serviti da OCP Studio delle funzionalità già messe a disposizione da PRISMA Studio di altri software/progetti che possono essere integrati Attività : Passata Definita l'architettura del servizio Definiti scenari come backup e restore di macchine virtuali e volumi – workflow che automatizzerà il processo di creazione di snapshot e backup di VMs, e backup di volumi, sulla base di parametri geografici e temporali decisi dall’utente DRaaS e MultiRegion OpenStack - Considerata la possibilità di utilizzare l'object storage distribuito geograficamente per il disaster recovery di dati non strutturati. Futura Sudiare e presentare 3 scenari: DRaaS con sistemi di storage distribuiti esterni (DRBD) DRaaS Applicativo con replica dei dati su sito remoto (DBMS Active/Passive, Active/Active) Backup automatico di VM e salvataggio su sito remoto Applicare ad alcuni casi d’uso concreti: DB postgresql, server http, set di applicaz .tipiche Almaviva – il caso DB applicativo – stusio soluzioni OpenSource – MetricsDB fatte prove funzionali in arch diverse, multinode, e prove prestazionali In previsione finire le prove, fare una relaione sui risultati dei test funz e prestaz. - pronta entro sett. in ottica delle cose decise - delineare la soluzione per OCP, una soluz del tipo procedurale, come contributo all D2.3

AR 2.5 “Implementazione e test di una interfaccia di cloud management comprendente funzionalità di monitoring avanzato, deployment di applicazioni in cluster, disaster recovery” Attivita’ di tipo Sviluppo Sperimentale, M8 – M42 (M29) Lead: INFN 6 pm - Partner: Santer Reply 18 pm, Almaviva 2 pm Singolo servizio, a livello Infrastructure, corrispondente al componente architetturale Gestione Virtual Environment Strato di mediazione tra infrastrutture IaaS differenti Include funzionalita’ di Monitoring/Billing, CFaaS e DRaaS Il tutto reso disponibile attraverso la Cloud Management Interface: apposite API (eventuali adattattamenti/estensioni di OCCI, CIMI, EC …. Modifiche: Il servizio conterrà funzionalità di: monitoring avanzato, per una struttura di monitoring integrato deployment di applicazioni in cluster, per ottenere gruppi di risorse cooperanti per applicazioni complesse (Cloud Formation as a Service - CFaaS) disaster recovery, per la definizione di politiche di affidabilità e disponibilità per le applicazioni implementate sulla piattaforma OCP Attività: Passata iniziati test delle soluzioni proposte sui testbed disponibili Repository open del codice - https://baltig.infn.it/ Futura Si userà il task per racogliere le sui testbed deployata (service endpoints) in uno xls, I tenant dove sono deployati i vari componenti Descrizione test eseguiti

OR 2 - Deliverables D2.1 (M 14) - Analisi dello stato dell’arte per interfacce di cloud management e dei componenti relativi mutuati da altri progetti, per il servizio di monitoring e billing, per la modellizzazione di applicazioni e servizi in Cloud e per il servizio di disaster recovery D2.2 (M24 (M 17))- Descrizione delle componenti di cloud management, monitoring e billing, modellizzazone di applicazioni e servizi in cloud e disaster recovery rilasciate nel primo prototipo per i servizi rilasciati dal WP2 e metriche per la loro valutazione D2.3 (M37 (M28)) - Descrizione delle componenti di cloud management, monitoring e billing, modellizzazone di applicazioni e servizi in cloud e disaster recovery rilasciate nel prototipo finale per i servizi rilasciati dal WP2 e metriche per la loro valutazione

SAL OR2 Da rivedere nell’ottica dei cambiamenti introdotti Contributi Eventuali spostamenti descrizione attività da OR11 (AR11.1 e AR11.2) a AR2.3 Contributi Mancanti: Reply