06/02/13Workshop CCR -- Sessione Cloud
Outline Perché parlare di Cloud Storage Come si adattano i requisiti Cloud ad un servizio di storage Elastico, On Demand, High Availability, High Level API, Trasparenza alla piattaforma di back- end, … È anche una questione di interfacce: Posix, REST Web Service, Amazon APIs, CDMI Nuove potenzialità in un sistema di Cloud Storage Disaster Recovery Storage as a Service Software disponibili per i vari use cases: Swift, OwnCloud, GlusterFS, HDFS, CEPH Schema generale Soluzioni Cloud Storage like in HEP Conclusioni 06/02/132Workshop CCR -- Sessione Cloud
Cloud storage: perché?Cloud storage: perché? Perché il “computing” non può fare a meno dei dati Se il Computing è di tipo Cloud, lo storage non può essere di tipo “tradizionale” L’apertura dei servizi Cloud a nuove comunità di utenti meno abituati a trattare grandi quantità di dati pone nuove sfide Interfacce più evolute, di più alto livello Che possano essere usate anche da programmi più generali come workflow manager, web service, etc. I dati devono essere disponibili e condivisi anche all’esterno dell’infrastruttura che li ha prodotti/processati Anche le semplici attività di utente finale possono beneficiare della de-localizzazione del servizio di storage 06/02/13Workshop CCR -- Sessione Cloud3
Requisiti per un Cloud StorageRequisiti per un Cloud Storage Nel caso di Cloud Computing siamo abituati a chiedere che un servizio di Cloud sia: Elastico e On-Demand: La quantità di istanze di computing deve essere dinamica e correlata alle effettive necessità dell’utente High Availability: L’istanza di Computing non deve essere sensibile ad eventuali fallimenti di un componente hardware usato per fornire il servizio High Level API: Deve essere possibile controllare le istanze di computing con delle API di alto livello (Web Services, etc) Accesso trasparente al servizio: Deve essere possibile usare le risorse di calcolo in modo trasparente dall’hardware o dal software usato dallo specifico sito 06/02/134Workshop CCR -- Sessione Cloud
Requisiti per un Cloud StorageRequisiti per un Cloud Storage Gli stessi requisiti devono essere validi anche per quanto riguarda lo storage: Accedere allo storage in modo dinamico ed elastico: All’aumentare delle richieste dell’utente lo storage deve essere reso disponibile dinamicamente in modo “elastico” High-Availability: La disponibilità dei files e dello storage non deve dipendere dalla failure di un singolo device hardware High Level API: La possibilità di accedere ai dati non solo tramite standard POSIX ma anche attraverso una interfaccia programmatica (Web Service) che consenta l’accesso standard da remoto Accesso trasparente allo storage: L’utente deve essere in grado di accedere allo storage e ai files indipendentemente dell’hw usato dal centro di calcolo 06/02/135Workshop CCR -- Sessione Cloud
Le interfacce sono importantiLe interfacce sono importanti Le interfacce di Amazon sono ormai uno standard di fatto: S3 è supportata da tutti i sistemi di IaaS Open Source Consente sia l’accesso tramite API da vari linguaggi di programmazione Consente l’accesso tramite REST e SOAP Services Consente sia l’accesso a “Buckets” che ad Oggetti Funzionalità molto avanzate (partial upload, ACL, autenticazione con token, etc) All’estremo opposto dell’astrazione c’è lo use-case di un device hardware che può essere “agganciato” ad una specifica istanza di macchina virtuale per essere formattato secondo le esigenze dell’utente In questo caso i device possono o meno resistere al riavvio/distruzione di una macchina virtuale 06/02/136Workshop CCR -- Sessione Cloud
Le interfacce sono importanti (2)Le interfacce sono importanti (2) La SNIA (Storage Networking Industry Association) ha definito una standard di accesso allo storage “Cloud Data Management Interface” (CDMI) “The underlying storage space exposed by the above interfaces is abstracted using the notion of a container” La nozione di container è utile non solo per catalogare i dati, ma anche per poterli trattare in modo aggregato, soprattutto sfruttando le possibilità fornite dall’uso congiunto di CDMI e OCCI: È possibile memorizzare i dati seguendo regole diverse in base al “container” di cui fanno parte È possibile agganciare un “container” ad una immagine virtuale in modo da utilizzarlo come disco virtuale e accederci via Posix. Un client crea un "container" usando l'interfaccia CDMI e lo esporta come un "OCCI export". Ottiene un ObjectID come risultato Il client crea un Virtual Machine usando l'interfaccia OCCI, e aggancia uno storage volume di tipo CDMI usando l'ObjectID. Il client ottiene un Virtual MachineID come risultato Il client aggiorna il "container" CDMI con l'ID della Virtual Machine in modo da consentire l'accesso al "container” Il client fa partire la macchina virtuale, che troverà il "container" come un device di storage 06/02/137Workshop CCR -- Sessione Cloud
Object Storage: OpenStack SwiftObject Storage: OpenStack Swift Uno dei software OpenSource più usati e più completi per fornire un’interfaccia Object Storage è Swift Sviluppato come uno dei componenti di OpenStack Funzionalità avanzate: data availability basata sulla replica dei dati: Possibilità di definire “zone” in modo da ottenere funzionalità di disaster recovery anche su WAN Scalabilità sia dello spazio di storage che dei metadati Il namespace non è in un DB o simili ma basato su consistent hashing Possibilità di aggiunta di nodi di storage in modo trasparente I nodi possono essere semplici file-server che scrivono binary files REST API Possibilità di accedere ad oggetti memorizzati nei “bucket” API in molti linguaggi di programmazione (C/C#, php, python, etc) 06/02/13Workshop CCR -- Sessione Cloud8
Object Storage: OpenStack SwiftObject Storage: OpenStack Swift 06/02/13Workshop CCR -- Sessione Cloud9
Nuovi storage system per le CloudNuovi storage system per le Cloud Ceph ( provides an infinitely scalable Object Store. It is based upon RADOS ( Its high-level features include providing a native interface to the Object Store via librados, and a number of service interfaces built on top of librados. These include: Block Devices : The RADOS Block Device (RBD) service provides resizable, thin-provisioned block devices with snapshotting and cloning. Ceph stripes a block device across the cluster for high performance. Ceph supports both kernel objects (KO) and a QEMU hypervisor that uses librbd directly–avoiding the kernel object overhead for virtualized systems. RESTful Gateway : The RADOS Gateway (RGW) service provides RESTful APIs with interfaces that are compatible with Amazon S3 and OpenStack Swift. Ceph FS : The Ceph Filesystem (CephFS) service provides a POSIX compliant filesystem usable with mount or as a filesytem in user space (FUSE). Ceph can run additional instances of OSDs, MDSs, and monitors for scalability and high availability. 06/02/13Workshop CCR -- Sessione Cloud10 CEPH
06/02/13Workshop CCR -- Sessione Cloud11 CEPH Ogni servizio critico può avere molte istanze contemporanee per scalabilità e ridondanza Il placement è basato su un algoritmo: i metadati non sono più il collo di bottiglia Ogni singolo oggetto può essere scritto splittandolo in “stripe unit” per aumentare le performance
Nuovi storage system per le CloudNuovi storage system per le Cloud CEPH è alla seconda release “stable” dopo anni di sviluppo continuo Il progetto è OpenSource (LGPL version 2.1) ma è attualmente supportato da una company (Inktank) che vende supporto enterprise Al momento i due principali software IaaS (OpenStack e CloudStack) hanno aggiunto a vari livelli il supporto a CEPH nel codice OpenStack per: immagini e volumi CloudStack per: block storage 06/02/13Workshop CCR -- Sessione Cloud12 CEPH
Cloud Storage: nuove possibilitàCloud Storage: nuove possibilità La “dematerializzazione” dello storage si traduce nel caso delle cloud pubbliche (Amazon) anche nella possibilità di avere/chiedere repliche dei propri files in più di un data-center Possibilmente distribuiti geograficamente Anche per implementazioni di cloud private, è un tema di assoluto interesse In un ambiente come il nostro abituato a trasferimenti di grosse quantità di dati in ambiente geograficamente distribuito In questo senso sono in corso diverse sperimentazioni per sfruttare software open-source per costruire infrastrutture di storage che possano offrire Disaster Recovery Hadoop-fs (HDFS) GlusterFS 06/02/13Workshop CCR -- Sessione Cloud13 Distaster RecoveryDistaster Recovery
HDFS: Hierarchical placement policyHDFS: Hierarchical placement policy è stato effettuato uno sviluppo su HDFS per dotare questo sistema di: Awareness of hierarchical network topology 2 replicas in local farm but in different racks 1 replica on a rack of remote farm Tolerance of whole farm fault Self-healing Synchronous 14Workshop CCR -- Sessione Cloud06/02/13
Hierarchical placement policyHierarchical placement policy 15Workshop CCR -- Sessione Cloud06/02/13
GlusterFS geo-replicationGlusterFS geo-replication GlusterFS nella versione 3.3 ha funzionalità di replica geografica Master-slave Basato su rsync Asincrono GlusterFS 3.4 prometteva di poter avere configurazioni di geo-replica multi-master, ma questa funzionalità è stata per il momento spostata alla versione 3.5 (~ +6 mesi) Inoltre, GlusterFS ha anche una interfaccia Object Storage compatibile con quella di Swift 16Workshop CCR -- Sessione Cloud06/02/13
GlusterFS geo-replication scenariosGlusterFS geo-replication scenarios 06/02/13Workshop CCR -- Sessione Cloud17
Data in the CloudData in the Cloud Dropbox è uno dei programmi di successo che hanno portato il cloud storage nell’uso giornaliero per tutti Il concetto è semplice è potente: Avere una copia dei propri dati in un posto in cui possono essere acceduti da qualsiasi computer Avere la possibilità di condividere una parte dei propri dati con i propri collaboratori Avere la possibilità di condividere pubblicamente una parte dei propri dati Avere la possibilità di sincronizzare i propri dati su più di una stazione di lavoro Esiste almeno un software OpenSource che permette di fare più o meno le stesse cose in una cloud privata: ownCloud 06/02/13Workshop CCR -- Sessione Cloud18
ownCloud Diverse sedi INFN stanno sperimentando questa soluzione con vari livelli di esperienza (LNGS, Torino e Bari) Sistema di sincronizzazione desktop-server efficiente Gestione via web di sharing dei files sufficiente per piccoli gruppi di lavoro Buona gestione del versioning dei files Le funzionalità più avanzate (uso di storage esterno, autenticazione avanzate, etc) sono meno solide Sembra una soluzione molto promettente anche in vista degli sviluppi futuri previsti Già ora potrebbe risolvere alcuni problemi per alcune comunità di utenti dove la dimensione dei files non è un fattore critico 06/02/13Workshop CCR -- Sessione Cloud19
ownCloud [2]ownCloud [2] 06/02/13Workshop CCR -- Sessione Cloud20
06/02/13Workshop CCR -- Sessione Cloud21 Le funzionalità di sharing sono potenti e intuitive da usare È anche possibile creare gruppi di utenti, in user-space, a cui dare i permessi
GARRbox 06/02/13Workshop CCR -- Sessione Cloud22 Prototipo di Cloud Storage con accesso via IDEM Simile a DropBox ma realizzato da un ente italiano I dati risiedono sul suolo italiano, legislazione chiara Policy sui dati concordate tra pari e non imposte dall’alto Funzionalità al momento non presenti rispetto ad altre soluzioni Client di sincronizzazione Risorse per lo sviluppo ed il supporto utente Economia di scala e supporto di terze parti commerciali (storage su Amazon S3) GARRbox tramite IDEM fornisce le seguenti funzionalità Creazione delle chiavi Amazon S3 Condivisione pubblica di file Condivisione di cartelle tra gli utenti del sistema Quote differenziate per utente, gruppo ed ente Replica locale e geografica dei dati
Cloud Storage: Schema generaleCloud Storage: Schema generale 06/02/13Workshop CCR -- Sessione Cloud 23 Local -- iSCSI /home Amazon S3 WebDav Dropbox/ ownCloud Block storage Volume Storage Object Storage (ma non solo DropBox è Cloud Storage!)
Federazioni di XrootdFederazioni di Xrootd Già da tempo gli esperimenti LHC utilizzano sistemi di tipo Cloud Storage come ad esempio le federazioni di Xrootd 06/02/13Workshop CCR -- Sessione Cloud24 all.role manager all.manager leftregion:1234 all.manager meta xyzzy:1234 xrootd.redirect xyzzy:1234 ? / all.role manager all.manager rightregion:1234 all.manager meta xyzzy:1234 xrootd.redirect xyzzy:1234 ? / Global Redirector Regional Redirector Local RedirectorProxy ServerProxy ManagerLocal Redirector ServerProxy ServerServer all.role meta manager all.manager meta xyzzy:1234 all.role manager all.manager lefthand:1234 all.manager meta leftregion:1234 xrootd.redirect leftregion:1234 ? / all.role manager all.manager righthand:1234 all.manager meta rightregion:1234 xrootd.redirect rightregion:1234 ? / all.role server all.manager leftregion:1234 ofs.osslib psslib.so pss.origin mycluster:1094 all.role proxy manager all.manager meta leftregion:1234 xrootd.redirect xyzzy:1234 ? / Site DSite ASite BSite C Andrew Hanushevsky (SLAC)
Federazioni di Xrootd [2]Federazioni di Xrootd [2] Vari sistemi di autenticazione X509 (ATLAS, CMS) Token (ALICE) Lo scopo è sempre il medesimo Fornire i dati in modo trasparente, anche con accesso in WAN, con o senza caching Scalabilità orizzontale e verticale, quindi con possibilità di espansione dei singoli storage e di aggregare più storage in modo efficiente Protocolli di accesso non-standard (Xrootd), ma largamente diffusi (EPEL) 06/02/13Workshop CCR -- Sessione Cloud25 Andrew Hanushevsky (SLAC)
Federazioni di HTTPFederazioni di HTTP Una alternativa alle federazioni di HTTP alla quale gli esperimenti di LHC stanno dimostrando interesse è la federazione di HTTP HTTP è un protocollo di accesso eccellente, e soprattutto standard e diffuso capillarmente Supporto nativo per le redirezioni Efficace in termini di performance e robustezza in applicazioni WAN Supporto per l’accesso diretto ai dati e ai metadati Può essere utilizzato come protocollo di controllo di clustering Possibilità di federare service HTTP e DAV 06/02/13Workshop CCR -- Sessione Cloud26
Conclusioni e domandeConclusioni e domande Il Cloud Storage è un complesso di sistemi relativamente nuovo, ma che si basa su tecnologie per la maggior parte già consolidate Forse sarebbe più opportuno chiamarlo semplicemente “Storage Distribuito”? Quali sono le necessità di accesso ai dati nell’INFN? Gli esperimenti LHC sono in qualche modo vincolati dalle scelte centrali, anche se è comunque possibile proporre soluzioni alternative Vari tipi di applicazioni (macro aree) Accesso a grandi moli di dati ad alte performance Disaster recovery Storage distribuito per utenti finali (DropBox-like) … Condivisione e razionalizzazione delle risorse? Difficilmente applicabili per i grandi utenti come gli esperimenti LHC, dove i modelli di calcolo, per il momento, sono profondamente radicati nelle tecnologie Grid Per il resto è importante valutare l’opportunità del Cloud Storage Base per sistemi completi di failover over WAN! Interesse delle Sezioni nel testare le varie soluzioni? 06/02/13Workshop CCR -- Sessione Cloud27