06/02/13Workshop CCR -- Sessione Cloud. Outline  Perché parlare di Cloud Storage  Come si adattano i requisiti Cloud ad un servizio di storage  Elastico,

Presentazione sul tema: "06/02/13Workshop CCR -- Sessione Cloud. Outline  Perché parlare di Cloud Storage  Come si adattano i requisiti Cloud ad un servizio di storage  Elastico,"— Transcript della presentazione:

1 06/02/13Workshop CCR -- Sessione Cloud

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 Object Storage: OpenStack SwiftObject Storage: OpenStack Swift 06/02/13Workshop CCR -- Sessione Cloud9

10 Nuovi storage system per le CloudNuovi storage system per le Cloud  Ceph (http://ceph.com/) provides an infinitely scalable Object Store.http://ceph.com/  It is based upon RADOS (http://ceph.com/papers/weil-rados-pdsw07.pdf)http://ceph.com/papers/weil-rados-pdsw07.pdf  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

11 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

12 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

13 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

14 HDFS: Hierarchical placement policyHDFS: Hierarchical placement policy  @INFN-Bari è 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

15 Hierarchical placement policyHierarchical placement policy 15Workshop CCR -- Sessione Cloud06/02/13

16 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

17 GlusterFS geo-replication scenariosGlusterFS geo-replication scenarios 06/02/13Workshop CCR -- Sessione Cloud17

18 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

19 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

20 ownCloud [2]ownCloud [2] 06/02/13Workshop CCR -- Sessione Cloud20

21 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

22 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

23 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!)

24 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)

25 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)

26 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

27 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