Claudio: Scopo riunione: scrittura di un documento che presenti architettura e piano di lavoro per arrivare ad avere una cloud di produzione INFN. Inoltre e’ stato richiesto a CCR di definire le policies per l’inclusione di infrastrutture “esterne” frutto ad esempio di collaborazioni con enti esterni (Cloud Padovana, in collab con Universita’ di Padova, la cloud di Torino, i progetti RECAS, …)
Giacinto: E’ importante definire come si relaziona la nostra infrastrutture con le altre . Per questo aiuteranno gli sviluppi previsti in diversi progetti, tipo INDIGO.
Dario: Una cloud ha un limite fondamentale nel dimensionamento. Deve poter risolvere tutte le richieste - quindi deve fare un bursting su altre cloud
Giacinto: Il cloud-bursting non entra nel ottica della singola istanza
Giuseppe: L’integrazione fra infrastrutture diverse puo’ avvenire a livello PaaS o Iaas tramite orchestrazione delle risorse. Lavorare con risorse limitate e’ comune all’ambiente della ricerca scientifica. Grid e’ stato un sistema per mettersi d’accordo. Con cloud si introduce una semplificazione notevole - l’estensione delle risorse si puo’ fare a liv PaaS, liv piu’ alto, curarsi poco di quello che c’e’ sotto, richiede meno uniformita’ a livello basso, e semplifica la collaborazioni tra enti diversi
Dario: La chiave essenziale e’ l’allargamento delle risorse. Se alcuni gruppi hanno bisogno di certe caratteristiche forse serve averle a livello IaaS
Davide: Dare accesso a risorse esterne al dominio amministrativo INFN ( come nella cloud padovana) e piu’ complicato che avere risorse solo INFN, Comunque bisogna prevedere l’integrazione di risorse non omogenee: le risorse di Torino sono sicuramente INFN e non possono essere lasciate fuori anche se utilizzano OpenNebula. Per quanto riguarda cloud-bursting, nel documento inviato da Stefano Stalio uno dei casi d’uso e’ il supporto con sottomissione non interattiva di job e l’allocazione di risorse che ci porta l’accodamento delle richieste. E’ piu’ urgente risolvere il problema della gestione della coda di richieste, poi si va sul bursting.
Giacinto: tecnicamente se abbiamo un unica istanza openstack possiamo fare piu’ cose che se abbiamo altri “tipi” cloud
Stefano Bagnasco: Il fatto di non avere OpenStack come stack di riferimento non serve solo a includere le risorse di Torino, ma anche per evitare un lock-in che ci lega ad una tecnologia che ha una roadmap lunga, ma non sicura come tutte. Garantirsi un po’ di disomogenita’ ci aiuta.
Claudio D’accordo: bisogna mantenere la biodiversita’ . Noi siamo in grado di avere una infrastruttura consistente in tuto INFN che puo’ funzionare come una CloudMR ma dobbiamo essere gia’ da prima in grado di gestire cloud non omogenee. E’ piu’ urgente non tanto il deployment della CloudMR ma la capacita’ di sfruttare la tecnologia cloud in senso lato. Dopo esiste il modello la cloud-mr che ci puo aiutare ad ottimizzare varie cose. L’eterogeneita’ e’ il punto chiave di INDIGO
Federico Zani Lo use case per l’utente finale e’ PaaS o IaaS?
Dario Dobbiamo capire dal modello dei esperimenti
Bagnasco Dipende dalla scala dei tempi con cui le cose vengono/verranno fatte. Allo stato attuale i grossi esperimenti si stanno basando su IaaS
Giacinto: Non possiamo chiedere ai utenti - loro vogliono le risorse per eseguire i job, non gl’interessa come. E’ una scelta tecnica di come vogliamo offrire i servizi. Abbiamo bisogno di funzionalita’ - e quella e’ a livello PaaS.
Claudio Riportiamo il fuoco di questa discussione assumendo che l’infrastruttura sia basata su una situazione disomogenea e vediamo quali sono gli use case che vogliamo affrontare. Come appare nel capitolo del documento, ci sono altri use case oltre a quello del fornire risorse in modo batch agli esperimenti. In particolare sono piu’ urgenti la razionalizzazione dei servizi offerti dai centri di calcolo, il supporto all’analisi interrattiva e il supporto dei piccoli esperimenti che non usano modelli di calcolo distribuiti. Per il momento possiamo fornire le risorse ai grossi esperimenti per calcolo in modalita’ “grid-replacement” con un modello IaaS, cosa che sappiamo gia’ gestire.
Dario Alice ha menzionato le cloud ma non ha specificato se PaaS o IaaS
StefanoB Alice assume IaaS esplicitamente, perche’ non sa come sia’ fatta la PaaS
Claudio: Proposta operativa: lavoriamo su due documenti. Uno piu’ tecnico specificatamente sulla CloudMR e uno che affronta il problema in modo piu’ ampio, partendo dagli use case che vogliamo affrontare. Ora ci concentriamo su questo secondo documento.
Giuseppe CHAINREDS e PRISMA hanno gia’ affrontato i sistemi d’orchestrazione che si possono adattare al sistema che vogliamo costruire. In particolare PRISMA ha sviluppato un sistema robusto per l’orchestrazione di risorse PaaS ed in WP5 c’e’ con due task e’ uno dei obbietivi importanti dei prossimi mesi Nel documento bisogna far emergere la dualita’: alcuni use-case si possono realizzare bene con CloudMR, altri con una infrastruttura di orchestrazione
Davide: Dal documento di Stefano Stalio, che e’ la base della implementazione tecnica della CloudMR, non emerge che cosa e’ gia’ possibile fare, quali degli use-case e’ possibile indirizzare con le soluzioni che abbiamo e quali richiedono uno sviluppo fatto in altri progetti come INDNGO. E; importante non solo cosa sara’ possibile fare in futuro ma anche cosa possiamo fare gia’ da adesso. Ad esempio la gestione di servizi o un sistema di ObjStorage, da interfacciare ad un sistema esterno come OpenNebula (usano Swift) si possono implementare in tempi ragionevolmente brevi (6 mesi)
Claudio: Proposta di classificare gli use case in 3 categorie 1 - possiamo gia’ implementare da subito 2 - implementare su una infrastr disomogenea con orchestratore IaaS 3 - richiedera’ una vera e propria una CloudMR
Giacinto: Meglio definire delle roadmap definendo delle milestones. Ad esempio da qua a 3 mesi offriamo questo servizio con questa tecnologia che risolve questo use case
Giuseppe Andronico: Includere anche la parte di federazione su cui si lavora a Catania puo aggiungere delle prospettive interessanti. La federazione CT non avrebbe bisogno di orchestratore, avrebbe un suo ambito d’utilizzo che andrebbe definito.
Claudio Importante descrivere le tecnologie che abbiamo a disposizione e avere ben presente l’architettura a cui vogliamo puntare.
Giuseppe Andronico E’ piu’ utile partire dagli use case
Giacinto: Suggerimento di prioritizzare gli use case in funzione delle tecnologie che gia’ abbiamo o posiamo sviluppare.
Claudio: Allora si parte dagli use case. Definiamo chi scrive le diverse sezioni. Local computing services Hosting of services addressing the needs of individual INFN sites and managed by personnel of the sites themselves. Development of PaaS services to standardize the implementation of common services. Qualcuno coinvolto nella gestione di servizi? Gia’ da oggi posso utilizzare una infrastruttura disomogenea: identifico un provider e faccio hosting di questi sistemi, poi in una CloudMR posso aggiungere altre funzionalita'.
… Serve accesso via portale su cloud diverse
Giuseppe Andronico Abbiamo studiato come supportare i servizi di sezione
Stefano Bagnasco A Torino ci sono tutti i servizi grid che girano sulla cloud
Stefano Stalio: I servizi web, il mailing, … possono essere il primo target di una CloudMR: gestire i siti web dell’INFN, di esperimento; il sistema dropbox-like; lo storage; la gestione distribuita su piu’ sedi in maniera HA, DB dei servizi
Claudio: Il contesto e’ che non sara’ piu’ finanziato hardware in ciascuna sede locale per evitare di mantenere tanti piccoli data-center. L’amministratore locale avra’ un pool di risorse a sua disposizione sulla cloud INFN per creare e gestire i servizi che gli servono. Quindi serve descrivere quello che si puo’ fare gia’ da ora in una cloud non omogenea e poi spiegare il valore aggiunto offerto da una CloudMR. Importante capire quali sono le tempistiche per una CloudMR che possa sodisfare queste esigenze nel prossimo futuro e spiegare come si puo’ gestire la situazione nel frattempo.
Davide: Per gli use cases dei local computing services conviene concentrarsi sulla CloudMR. Inoltre e’ gia’ possibile oggi offrire servizi a livello PaaS ad esempio per la creazione dei web-servers che si appoggiano a backend distribuiti come gia’ fatto in OCP: istanziare in maniera grafica questi oggetti, e instanziarli sulla CloudMR Cosi mettiamo insieme la parte IaaS che si connette alla CloudMR con la PaaS dove INFN ha esperienza (OCP).
Claudio Perfetto, pero’ serve capire in quanto tempo si possono avere prototipi e sistemi in pre-produzione.
Stefano Stalio La difficolta’ e’ avere delle risorse. I tempi sono brevi se c’e’ aiuto da parte dell'ente.
Davide: L’importante e’ che sia operativo e che funzioni
Segue una discussione su risorse e tempi. La conclusione e’ che in autunno si puo’ avere una infrastruttura CloudMR di pre-produzione con 3 sedi: CNAF, BA, LNGS.
Claudio: Allora Stefano Stalio e gli altri del gruppo CloudMR possono descrivere la roadmap nel contesto CloudMR. Vorrei pero’ avere anche l’opinione di qualcuno che gestisce una delle “cloud esterne” su come vedono l’integrazione. Ad esempio Cristina potrebbe contattare Massimo Sgaravatto per chiedere come vede dal punto di vista tecnico l’integrazione della Cloud-padovana.
Passiamo al punto successivo: Central computing services Provisioning of central services such as: • Authentication and Authorization tools • DBMS • VPNaaS • Web applications • Collaborative tools and information sharing • Administrative tools • Teaching and technology transfer (e-learning, on-line laboratories, …) Quali di questi use case possono essere sodisfati da una cloud-federata e/o con un orchestratore?
Giacinto: Facciamo mente locale tecnicamente per fare il roadmap con StefanoB e Andronico
Claudio: Punto successivo: Scientific computing Address the same use cases currently addressed by Grid computing: • Provisioning of massive computing power in batch-mode with dynamic resource allocation • Provisioning of storage capacity and data distribution over the WAN • Automation of complex workflows Claudio puo’ sicuramente scrivere il punto di vista dei grossi esperimenti. Serve qualcuno di INDIGO che si occupi degli aspetti piu’ specifici. Dario: Menzionare le esperienze sulle cloud HLT degli esperimenti LHC?
Claudio: Per quanto riguarda CMS la cloud HLT ha permesso di fare studi di fattibilita’ e test di scalabilita’, ma durante run2 sara’ utilizzata tramite un semplice virtualizzatore che fa partire macchine che entrano direttamente nel global pool di HTCondor. Sono invece piu’ significative le attivita’ sulla Agile Infrastructure del CERN (su cui girera’ il Tier-0 e la CAF) e i test su risorse cloud a Padova fatte da Massimo ed altri test da inglesi.
Davide: Davide puo dare una mano per la parte INDIGO.
Stefano Bagnasco: Partecipa per Alice
Claudio: Il provisioning di storage capicity lo vogliamo affrontare da subito? Sara’ a lungo termine?
Stefano Bagnasco: Se si vuole una virtual farm on –demand serve affrontarlo da subito.
Giacinto: Disponibile per descrivere l’automazione di workflow complessi (WP6 diINDIGO)
Claudio Punto successivo: Support to analysis Address the needs of end users and of small collaborations, including the so-called last-mile of analysis. • Personal storage • Provisioning of interactive computing power • Ad-hoc solution for specific needs Il personal storage lo abbiamo gia’ affrontato (da fornire a livello prototipale su CloudMR). Se ne occupano Stefano Stalio e Federico Zani. Dario ha esperienza nella parte di analisi interattiva e soluzioni per piccoli esperimenti. Puo’ occuparsi lui del resto del capitolo?
Dario Si’, infatti fa uso pesante di analisi interrattiva (ssh, aprire finestreX di editing e osservare risultati con n-tuple) C’e’ un problema di banda passante dovuta all’uso di X11
Claudio Pero’ ci sono tecnologie di fornire desktop-remoti
Giacinto In PRISMA c’e’ stata attivita’ che ha dato risultati e potra’ scrivere qualcosa.
Claudio: Allora Dario e Giacinto ci lavorano assieme. Importante descrivere quali sono le esigenze E descrivere se questo tipo di use-case puo’ essere affrontato su infrastrutture anche eterogenee. Il gruppo di Catania ha gia’ affrontato la cosa? Altri aspetti (come descritti nel proposal di INDIGO) per fornire i servizi a livello PaaS?
Giuseppe Andronico La federaz lavora a livello IaaS sarebbe trasparente alle attivita’ di livello PaaS, ma si si puo’ ragionare su e sviluppare il concetto.
Dario: Vale la pena di menzionare gli use case di telemedicina? forse usera’ cloud
Claudio: Per il momento meglio concentrarsi su use case INFN
Quindi per riassumere: per ogni punto bisogna descrivere in dettaglio gli use-case, descrivere le tecnologie che si vogliono utilizzare a diversi livelli, associandoli ad una scala temporale.
Per la prossima volta cerchiamo organizzare un meeting di persona
Altre cose: E’ stato chiesto di fornire dati quantitativi sul costo dell’implementazione di una infrastruttura Cloud. Quindi serve descrivere quante risorse hardware servono per creare la parte gestionale delle risorse cloud sia in ciascun data centre che a livello centrale. Ovviamente dipendera’ dalla dimensione totale del data center ma si puo’ partire dalle esperienze che gia’ abbiamo, almeno per fornire ordini di grandezza.
Davide: Puro hardware di supporto? Oltre alle macchine che servono per far funzionare l’infrastruttura di base ci sono i sistemi che servono per la ridondanza dello storage. Manpower?
Claudio: E’ essenziale anche la parte di valutazione del manpower. A fronte di un maggior costo di hardware potrebbe corrispondere un significativo risparmio nella parte gestionale.
Davide Il goal e’ di mostrare che siamo in grado di offrire un buon servizio, ma che il costo arriva, 1 mese gratis, 2 mese 50%
Claudio Il risparmio si raggiunge anche togliendo la parte di gestione hardware, che si concentra in un unico punto che gestisce il hardware per piu’ sedi. Quindi riassumendo: quando costa la gestione del sistema nel sito con l’hardware e quanto costa la gestione dei servizi centrali (come ad esempio il keystone nazionale) sia per hardware che per manpower.
Federico Zani: Serve lavorare a 4/6 mani. Se ne occupa il gruppo CloudMR e Bagnasco
Claudio: Come detto all’inizio e’ urgente definire le policy per l’inclusione di “siti esterni”. Le scelte saranno prevalentemente politiche ed economiche ma serve definire i vincoli tecnici.
Giuseppe Andronico: Dal punto di vista della federazione puo’ dare contributo
Claudio: Serve il contributo di persone che hanno esperienza in queste infrastrutture esterne come Stefano Bagnasco e Cristina (che ciedera’ a Massimo). Concentrarsi sui vincoli di tipo tecnico.
Segue discussione sul significato dei vincoli tecnici nei diversi contesti. Si fa notare che la questione e’ troppo vaga e il numero di parametri e’ troppo grande.
Claudio E’ possibile definire almeno alcuni punti fermi?
Davide Le policy d’addesione alla EGI FedCloud - potrebbero essere un punto di partenza.
Dario Lo scopo del documento e’ quello di definire una roadmap
Claudio Lo scopo fondamentale del documento e’ dimostrare che la CCR sta facendo cose concrete su cloud ed ha idee su come l’infrastruttura deve evolvere per sodisfare le esigenze INFN. L’aggiunta di elementi di tipo economico dipende da richieste fatte in seguito il cui scopo e di aiutare il management nella valutazione di richieste, cioe’ dire se vale la pena accettare alcune collaborazioni o meno.
Davide Importante che la CCR faccia vedere che c’e’ una roadmap per la costruzione di una cloud e che esiste un nucleo di persone competenti che possono valutare ciascun bussiness case quando si presenta.
Claudio Possiamo esplicitare almeno le condizioni per l’inclusione nella CloudMR?
Stefano Stalio: Serve un documento tecnico sulla CloudMR?
Claudio: Il documento generale di cui abbiamo discusso fara’ riferimento al doc tecnico con detagli su’implementazione della CloudMR.
Note di Davide :
+ "Alla base dell’infrastruttura proposta c’è OpenStack come soluzione di IaaS." –> e OpenNebula? Quali sono i piani per non lasciare ad esempio Torino fuori dalla Cloud INFN?
+ su network, è molto generico dire "ci dovranno essere dei rapporti di trust", ci sono proposte? Con chi ci si relaziona? Quello che non va bene è che il gruppo cloud venga visto non in sinergia con i gruppi o le persone che si occupano di rete.
+ sull'object storage, io menzionerei meglio quello che adesso è detto "distribuzione di dati scientifici", ovvero la possibilità data ad esperimenti, attraverso la cloud infn, di costruire i propri programmi con un modello di storage ad oggetti eventualmente automaticamente replicato.
+ monitoring "centralizzato e puntuale", toglierei "puntuale". Non dice che cosa viene monitorato.
+ sui syslog occorre parlare della gestione della security, per esempio come si trasferiscono i log da un sito a un altro nel caso di raccolta centralizzata. Non dice come verrà fatto (es. logstash?) mentre in altri casi si menzionano prodotti specifici (es. Foreman e Puppet).
+ PaaS, non mi è chiaro cosa c'entrino WNoDeS o U-Lite qui.
+ non c'è nessuna menzione di portali, che invece penso possano essere fondamentali ad esempio nella gestione dei workflow. Legato a questo, la suddivisone strettamente tra solo IaaS e PaaS mi pare limitante.
+ non si dice bene chi sono "i gestori della cloud infn". Nel paragrafo sulla gestione si accenna al supporto ma:
+ tutto pienamente distribuito probababilmente non funziona, credo che serva comunque identificare un posto di riferimento (un HQ virtuale?). Questo è legato all'identificazione di una struttura con chiare responsabilità. Ma più in generale, + serve identificare bene quali sono i ruoli. Dire che servono "un congruo numero di FTE" non vuol dire nulla. E poi bisogna essere realistici.
+ non c'è tempistica.
+ non si dice quali sono gli obiettivi di breve o medio termine, nè il modo in cui possano essere verificati.
+ non c'è legame esplicito tra i casi d'uso elencati (che mi sembrano corretti) e le esigenze degli esperimenti.
+ come si intende gestire in pratica un caso come l'utilizzo di risorse presenti in più centri in modo trasparente per gli utenti?
+ una figura dell'architettura proposta aiuterebbe a spiegare meglio anche a chi è più estraneo a questi argomenti che cosa si vuole fare.