Vai al contenuto

Object storage

Da Wikipedia, l'enciclopedia libera.

L'object storage (conosciuto anche come archiviazione basata su oggetti[1]) è una tipologia di memorizzazione che gestisce i dati come oggetti, al contrario di altre architetture di storage come i file system che gestiscono i dati come una gerarchia di file, e l'archiviazione a blocchi all'interno di settori e tracce.[2] Ogni oggetto in genere include i dati stessi, una quantità variabile di metadati, e un identificatore univoco globale. Lo storage a oggetti può essere implementato a più livelli, tra cui il livello di dispositivo (dispositivo di archiviazione a oggetti), il livello di sistema e il livello di interfaccia. In ogni caso con l'object storage si ha la possibilità di abilitare funzionalità non indirizzate da altre architetture di storage, come interfacce direttamente programmabili dall'applicazione, uno spazio dei nomi che può estendersi su più istanze di hardware fisico e funzioni di gestione dei dati come replica dei dati e distribuzione degli stessi a livello di granularità.

Lo storage di oggetti è utilizzato per vari scopi tra cui la memorizzazione di oggetti come video e foto su Facebook, canzoni su Spotify o file nei servizi di collaborazione online, come Dropbox.[3] Una delle limitazioni dello storage di oggetti è che non è destinato a dati transazionali, poiché il sistema non è stato progettato per sostituire l'accesso e la condivisione di file NAS, non supporta i meccanismi di blocco e condivisione necessari per mantenere una singola versione aggiornata di un file.[4]

Nel 1995, una ricerca condotta da Garth Gibson sui NAS promoveva per la prima volta il concetto di dividere le operazioni meno comuni, come le manipolazioni dello spazio dei nomi, dalle operazioni comuni come la lettura e la scrittura, per ottimizzare le prestazioni e la scalabilità di entrambe.[5] Nello stesso anno, è stata istituita una società belga, la FilePool, per costruire le basi per le funzioni di archiviazione. Lo stoccaggio di oggetti è stato proposto nel laboratorio della Carnegie Mellon University di Gibson come progetto di ricerca nel 1996. Un altro concetto chiave è stato l'astrazione della scrittura e della lettura dei dati in container più flessibili defintii "oggetti". Il controllo di accesso fine-grained attraverso l'architettura di archiviazione oggetti è stato descritto ulteriormente da uno dei membri del team NASD, Howard Gobioff, che successivamente fu uno degli inventori del Google File System.[6][7] Altri lavori correlati includono il progetto del file system Coda al Carnegie Mellon, iniziato nel 1987, che ha generato il file system Lustre.[8] C'è anche il progetto OceanStore presso l'UC Berkeley, iniziato nel 1999, e il progetto Logistic Networking presso l'Università del Tennessee Knoxville, iniziato in 1998.[9][10][11] Nel 1999, Gibson fondò Panasas per diffondere i concetti sviluppati dal team NASD.

Seagate Technology ha svolto un ruolo centrale nello sviluppo dello storage di oggetti. Secondo la Storage Networking Industry Association SNIA "L'archiviazione di oggetti ha avuto origine alla fine degli anni '90: le specifiche di Seagate dal 1999 introdussero alcuni primi comandi e la rimozione effettiva del sistema operativo dai consumi dello storage".[12]

Una versione preliminare della "OBJECT Based Storage Devices Command Set Proposal" del 25 ottobre 1999 è stata presentata da Seagate ed edita da Dave Anderson ed è stata il prodotto di lavoro del National Storage Industry Consortium (NSIC) che comprende i contributi di Carnegie Mellon University, Seagate, IBM, Quantum e StorageTek.[13] Il presente documento è stato presentato all'INCITS T-10 (Comitato internazionale per le norme sulle tecnologie dell'informazione) con l'obiettivo di costituire un comitato e di elaborare una specifica basata sul protocollo di interfaccia SCSI. Questo ha definito gli oggetti come dati astratti, con identificatori e metadati unici, come gli oggetti si relazionano ai sistemi di file, insieme a molti altri concetti innovativi. Anderson ha presentato molte di queste idee alla conferenza SNIA nell'ottobre 1999. La presentazione ha rivelato un accordo di proprietà industriale firmato nel febbraio 1997 tra i collaboratori originali (con Seagate rappresentato da Anderson e Chris Malakapalli) che copriva i vantaggi dello storage di oggetti, dell'informatica scalabile, dell'indipendenza della piattaforma e della gestione dello storage.[14]

Astrazione dello storage

[modifica | modifica wikitesto]

Uno dei principi di progettazione dello storage di oggetti è quello di astrarre alcuni livelli inferiori, quelli lontani dagli amministratori e dalle applicazioni. IIdati vengono così esposti e gestiti come oggetti invece di blocchi o file. Gli oggetti contengono proprietà descrittive aggiuntive che possono essere utilizzate per una migliore gestione e ne permette anche l'indicizzazione. Gli amministratori così non devono eseguire funzioni di archiviazione di livello inferiore come la costruzione e la gestione di volumi logici per utilizzare la capacità del disco o impostare i livelli RAID per affrontare problemi ai dischi.

L'object storage consente anche l'indirizzamento e l'identificazione di singoli oggetti da più di un semplice nome del file e dal percorso: viene aggiunti infatti un identificatore univoco all'interno di un bucket, o nell'intero sistema, per supportare spazi dei nomi molto più grandi ed eliminare le collisioni dei nomi.

Inclusione di metadati personalizzati all'interno dell'oggetto

[modifica | modifica wikitesto]

Lo storage di oggetti separa esplicitamente i metadati dei file dai dati per supportare funzionalità aggiuntive.

A differenza dei metadati fissi nei file system (nome del file, data di creazione, tipo, ecc.), lo storage di oggetti prevede metadati personalizzati a livello di oggetto al fine di:

  • Acquisite informazioni specifiche dell'applicazione o dell'utente per migliorare l'indicizzazione;
  • Definire la gestione dei dati di supporto (ad esempio una politica per guidare il movimento degli oggetti da un livello di storage ad un altro);
  • Centralizzare la gestione dello storage su singoli nodi e cluster;
  • Ottimizzare l'archiviazione dei metadati (ad esempio archiviazione incapsulata, database o valore chiave) e la memorizzazione nella cache/indicizzazione (quando i metadati autorevoli sono incapsulati con i metadati all'interno dell'oggetto) indipendentemente dall'archiviazione dei dati (ad esempio archiviazione binaria non strutturata)

Inoltre, in alcune implementazioni di file system basate su oggetti:

  • I client del file system contattano i server dei metadati solo una volta aperti e poi ottengono il contenuto direttamente tramite server di archiviazione di oggetti (per contro, file system basati su blocchi richiedono un accesso costante ai metadati);
  • Gli oggetti possono essere definiti per file con lo scopo di consentire l'adattamento dell'espansione, anche su più server di archiviazione di oggetti, supportando ottimizzazioni di larghezza della banda e input/output.

I dispositivi di archiviazione basati su oggetti (OSD) e alcune implementazioni software (ad esempio, DataCore Swarm) gestiscono i metadati e i dati a livello di dispositivi di archiviazione:

  • Invece di fornire un'interfaccia orientata ai blocchi che legge e scrive dati di dimensioni fisse, i dati sono organizzati in contenitori di varie grandezze, chiamati oggetti;
  • Ogni oggetto ha sia dati (una sequenza non interpretata di byte) che metadati (un insieme estensibile di attributi che descrivono l'oggetto); incapsulare entrambi insieme beneficia della recuperabilità;
  • L'interfaccia di comando include i comandi per creare e eliminare oggetti, scrivere e leggere byte da e verso oggetti specifici, e per impostare ed ottenere attributi su oggetti;
  • I meccanismi di sicurezza forniscono il controllo di accesso per singolo oggetto e per singolo comando;

Gestione programmatica dei dati

[modifica | modifica wikitesto]

Object storage fornisce interfacce programmatiche per consentire alle applicazioni di manipolare i dati. A livello base, questo include funzioni minime per creazione, lettura, aggiornamento ed eliminazione di dati (CRUD). Alcune implementazioni di object storage vanno oltre, supportando funzionalità aggiuntive come controllo delle versioni di oggetti/file, replica di oggetti, gestione del ciclo di vita e movimento di oggetti tra diversi livelli e tipi di storage. La maggior parte delle implementazioni API sono REST permettendo l'utilizzo di molte chiamate standard HTTPS.

Implentazione

[modifica | modifica wikitesto]

Storage cloud

[modifica | modifica wikitesto]

La stragrande maggioranza dello storage cloud disponibile sul mercato utilizza un'architettura di archiviazione di oggetti. Alcuni esempi notevoli sono Amazon Web Services S3, che è debuttato nel marzo 2006, Microsoft Azure Blob Storage, Rackspace Cloud Files (il cui codice è stato donato nel 2010 al progetto OpenStack e rilasciato come OpenStack Swift) e Google Cloud Storage rilasciato nel maggio 2010.

I file system basati su oggetti

[modifica | modifica wikitesto]

Alcuni file system distribuiti utilizzano un'architettura basata su oggetti, in cui i metadati dei file sono memorizzati nei server e i dati dei file sono archiviati nei server di archiviazione oggetti. Il software client del file system interagisce con i diversi server e li astrae al fine di disporre all'utente e alle applicazioni un file system completo.

Sistemi di archiviazione degli oggetti

[modifica | modifica wikitesto]

Alcune prime tipologie di object storage sono state utilizzate per l'archiviazione, poiché le implementazioni sono state ottimizzate per l'immutabilità, non per le prestazioni. EMCCentera ed Hitachi HCP (precedentemente conosciuti come HCAP) sono due prodotti per l'archiviazione di oggetti comunemente citati. Un altro esempio è la piattaforma di archiviazione di oggetti Quantum ActiveScale.

Più sistemi di archiviazione di oggetti a scopo generale sono arrivati sul mercato intorno al 2008. Attirati dall'incredibile crescita dei sistemi di archiviazione "captive" all'interno di applicazioni web come Yahoo Mail e dal primo successo dello storage cloud, i sistemi di archiviazione di oggetti promettevano la scalabilità, le capacità dello storage cloud e la possibilità di implementare il sistema all'interno dell'azienda o presso un fornitore di servizi di archiviazione cloud.

Storage unificato di file e oggetti

[modifica | modifica wikitesto]

Alcuni sistemi di archiviazione di oggetti supportano la memorizzazione unificata di file e di oggetti, consentendo ai clienti di memorizzare oggetti su un sistema di memorizzazione, mentre altri clienti memorizzano simultaneamente file sullo stesso sistema di memorizzazione.[15] Altri fornitori nell'area dello storage cloud ibrido utilizzano gateway di storage cloud per fornire un livello di accesso ai file su un archivio di oggetti, implementando protocolli di accesso a file come SMB e NFS.

Storage di oggetti "captive"

[modifica | modifica wikitesto]

Alcune grandi aziende di servizi digitali hanno sviluppato il proprio software quando i prodotti di archiviazione di oggetti non erano ancora disponibili in commercio o quando i casi d'uso erano molto specifici. Facebook ha inventato il proprio software di archiviazione di oggetti, denominato in codice Haystack, per soddisfare in modo efficiente le proprie esigenze di gestione delle foto su larga scala.[16]

Dispositivi di archiviazione basati su oggetti

[modifica | modifica wikitesto]

Adozione sul mercato

[modifica | modifica wikitesto]

Uno dei primi prodotti di archiviazione di oggetti, Lustre, è utilizzato nel 70% dei primi 100 supercomputer e circa il 50% dei Top 500.[17] A partire dal 16 giugno 2013, questo include 7 dei primi 10, tra cui il quarto sistema più veloce - il cineme Tianhe-2 - e il settimo più veloce, il supercomputer Titan all'Oak Ridge National Laboratory.[18]

I sistemi di archiviazione di oggetti hanno avuto un buon impiego nei primi anni 2000 come piattaforma di archivio, in particolare a seguito delle leggi di conformità come Sarbanes-Oxley. Dopo cinque anni di attività sul mercato, il prodotto Centera di EMC ha ottenuto oltre 3.500 clienti e 150 petabytes di spedizione fino al 2007.[19] Per HCP di Hitachi molti clienti richiedono sistemi di archiviazione su scala di petabyte.[20] I nuovi sistemi di archiviazione di oggetti hanno anche ottenuto un certo successo, in particolare nelle applicazioni personalizzate molto grandi come il sito di aste di eBay, dove EMC Atmos è utilizzato per gestire oltre 500 milioni di oggetti al giorno.[21] A partire dal 3 marzo 2014, EMC afferma di aver venduto oltre 1,5 exabyte di spazio di archiviazione Atmos.[22] Il 1º luglio 2014, il Los Alamos National Lab ha scelto lo Scality RING come base per un ambiente di archiviazione di 500 petabyte, che sarebbe stato tra i più grandi mai realizzati.[23]

I sistemi di archiviazione di oggetti "captive" come Haystack di Facebook sono cresciuti in modo impressionante. Nell'aprile 2009, gestiva 60 miliardi di foto e 1,5 petabyte di spazio di archiviazione, aggiungendo 220 milioni di foto e 25 terabyte a settimana.[16] Facebook ha recentemente dichiarato che aggiungeva 350 milioni di foto al giorno e che conservava 240 miliardi di foto,[24] il tutto quindi si aggirerebbe sui 357 petabyte.[25]

Lo storage cloud è diventato diffuso in quanto molte nuove applicazioni web e mobile lo scelgono come metodologia comune per memorizzare dati binari.[26] Come back-end di storage per molte applicazioni popolari come Smugmug e Dropbox, Amazon S3 è cresciuto su larga scala, avendo oltre 2 trilioni di oggetti memorizzati nell'aprile 2013.[27] Due mesi dopo, Microsoft affermò di aver memorizzato ancora più oggetti in Azure, a 8,5 trilioni.[28] Nell'aprile 2014, Azure ha rivendicato oltre 20 trilioni di oggetti memorizzati.[29] Windows Azure Storage gestisce Blobs (file utente), Tabelle (archiviazione strutturata) e Code (consegna di messaggi) e li conta tutti come oggetti.[30]

Analisi del mercato

[modifica | modifica wikitesto]

IDC ha iniziato a valutare annualmente il mercato dello stoccaggio basato su oggetti utilizzando la sua metodologia MarketScape. IDC descrive il MarketScape come: "...una valutazione quantitativa e qualitativa delle caratteristiche che valutano il successo attuale e futuro di un venditore in tale mercato o segmento di mercato e forniscono una misura della sua ascendenza per diventare un leader o mantenere una leadership. Le valutazioni di IDC MarketScape sono particolarmente utili nei mercati emergenti che sono spesso frammentati, hanno diversi attori e non hanno leader chiari".[31]

Nel 2019, IDC ha classificato Dell EMC, Hitachi Data System, IBM, NetApp e Scality come leader.

Dispositivi per archiviazione di oggetti

[modifica | modifica wikitesto]

OSD versione 1

[modifica | modifica wikitesto]

Nella prima versione dello standard OSD,[32] gli oggetti sono specificati con un ID partizione a 64 bit e un ID oggetto a 64 bit. Le partizioni vengono create ed eliminate all'interno di un OSD e gli oggetti vengono creati ed eliminati all'interno delle partizioni. Non ci sono dimensioni fisse associate a partizioni o oggetti, possono crescere in base alle limitazioni di dimensioni fisiche del dispositivo o ai vincoli di quota logica su una partizione.

Un insieme estensibile di attributi descrive gli oggetti. Alcuni attributi vengono implementati direttamente dall'OSD, come il numero di byte in un oggetto e il timestamp di modifica di un oggetto. C'è inoltre una speciale politica di etichettatura che fa parte del meccanismo di sicurezza. Altri attributi non sono stati interpretati dall'OSD. Questi sono impostati su oggetti dai sistemi di archiviazione di livello superiore che utilizzano l'OSD per lo storage persistente. Ad esempio, gli attributi potrebbero essere utilizzati per classificare oggetti o per individuare le relazioni tra diversi oggetti memorizzati su diversi OSD.

Un comando lista restituisce un elenco di identificatori di oggetti all'interno di una partizione, opzionalmente filtrato da corrispondenze rispetto ai loro attributi. Un comando di lista può anche restituire attributi selezionati degli oggetti elencati.

I comandi di lettura e scrittura possono essere combinati con i comandi per ottenere e impostare attributi. Questa capacità riduce il numero di volte in cui un sistema di archiviazione ad alto livello deve attraversare l'interfaccia con l'OSD, il che può migliorare l'efficienza complessiva.

OSD versione 2

[modifica | modifica wikitesto]

Una seconda generazione del set di comandi SCSI, "Object-Based Storage Devices - 2" (OSD-2), ha aggiunto il supporto per le snapshot, le raccolte di oggetti ed è stata miglioratala gestione degli errori.[33]

Un'istantanea è una copia puntuale di tutti gli oggetti di una partizione in una nuova partizione. L'OSD può implementare una copia efficiente nello spazio utilizzando tecniche di copy-on-write in modo che le due partizioni condividano oggetti che non sono cambiati tra diversi istanti, oppure potrebbe copiare fisicamente i dati nella nuova partizione. Lo standard definisce i cloni, che sono scrivibili, e gli istantanei, che sono solo leggibili.

Una collezione è un tipo speciale di oggetto che contiene gli identificatori di altri oggetti. Esistono operazioni per aggiungere e cancellare dati dalle collezioni, e ci sono operazioni per ottenere o impostare attributi per tutti gli oggetti in una collezione. Le raccolte sono utilizzate anche per la segnalazione degli errori. Se un oggetto viene danneggiato per la presenza di un difetto del supporto o per un errore software all'interno dell'implementazione di OSD, il suo identificatore viene inserito in una raccolta speciale di errori. Il sistema di archiviazione di livello superiore che utilizza l'OSD può consultare questa raccolta e, se necessario, adottare misure correttive.

Differenza tra chiave-valore e oggetti

[modifica | modifica wikitesto]

Il confine tra un object-storage e un sistema di archiviazione chiave-valore è labile, con l'archiviazione di elementi chiavie-valore che a volte vengono erroneamente indicati come oggetti.

Un'interfaccia di archiviazione di blocchi tradizionale utilizza una serie di blocchi di dimensioni fisse numerati a partire da 0. I dati devono essere di dimensione fissa e possono essere conservati in un blocco specifico che è identificato dal suo numero logico di blocco (LBN). In seguito, si può recuperare quel blocco di dati specificando il suo LBN univoco.

Con un archivio chiave-valore, i dati vengono identificati da una chiave anziché da un LBN. Una chiave potrebbe essere "gatto" o "olivo" o "42". Può essere una sequenza arbitraria di byte di lunghezza variabile. I dati (chiamati "valori" in questo contesto) non devono essere di dimensioni fisse e possono essere anche una sequenza arbitraria di byte di lunghezza variabile. Si memorizzano i dati presentando la chiave e i dati (valore) si possono recuperare in seguito presentando la sola chiave. Questo concetto è impiegato nei linguaggi di programmazione. Python li chiama dizionari, Perl li chiama hash, Java e C++ li chiamano mappe, ecc. Molti archivi dati implementano anche archivi di tipo chiave-valore come Memcached, Redis e CouchDB.

Gli object-store sono simili ai sistemi di archiviazione chiave-valore per due aspetti: in primo luogo, l'identificatore di oggetto o URL (l'equivalente della chiave) può essere una stringa arbitraria,[34] in secondo luogo, i dati possono essere di dimensioni arbitrarie.

Ci sono tuttavia alcune differenze tra object-storage e chiave-valore: i primi consentono anche di associare un insieme limitato di attributi (metadati) a ciascun dato. La combinazione di una chiave e di un valore e relativi di attributi definisce un oggetto. In secondo luogo, l'archiviazioni di oggetti sono ottimizzati per grandi quantità di dati (centinaia di megabytes o persino gigabytes), mentre per chiave-valore il valore dovrebbe essere relativamente piccolo (kilobytes). Infine, l'object-storagee offre di solito garanzie di coerenza più deboli mentre chiave-valore offrono una forte coerenza.

  1. ^ M. Mesnier, G.R. Ganger e E. Riedel, Storage area networking - Object-based storage, in IEEE Communications Magazine, vol. 41, n. 8, August 2003, pp. 84–90, DOI:10.1109/mcom.2003.1222722.
  2. ^ druva.com, http://www.druva.com/blog/object-storage-versus-block-storage-understanding-technology-differences/. URL consultato il 19 January 2015.
  3. ^ Chandrasekaran, Arun, Gartner Research, http://www.gartner.com/technology/reprints.do?id=1-1R78PJ9&ct=140226&st=sb.
  4. ^ qumulo.com, https://qumulo.com/blog/block-storage-vs-object-storage-vs-file-storage/. URL consultato l'8 February 2022.
    «"Object storage can work well for unstructured data in which data is written once and read once (or many times). Static online content, data backups, image archives, videos, pictures, and music files can be stored as objects."»
  5. ^ Garth A. Gibson, pdl.cmu.edu, http://www.pdl.cmu.edu/ftp/NASD/Sigmetrics97.pdf. URL consultato il 27 October 2013.
  6. ^ Gobioff, Howard, repository.cmu.edu, http://repository.cmu.edu/cgi/viewcontent.cgi?article=1147&context=pdl. URL consultato il 7 November 2013.
  7. ^ Sanjay Ghemawat, research.google.com, http://research.google.com/archive/gfs-sosp2003.pdf. URL consultato il 7 November 2013.
  8. ^ Copia archiviata (PDF), su ols.fedoraproject.org. URL consultato il 17 September 2013 (archiviato dall'url originale il 1º dicembre 2017).
  9. ^ oceanstore.cs.berkeley.edu, http://oceanstore.cs.berkeley.edu/. URL consultato il 18 September 2013.
  10. ^ John Kubiatowicz, Chris Wells e Ben Zhao, Proceedings of the ninth international conference on Architectural support for programming languages and operating systems, 2000, pp. 190–201, DOI:10.1145/378993.379239, ISBN 1581133170.
  11. ^ James Plank, Micah Beck e Wael Elwasif, The Internet Backplane Protocol: Storage in the Network (PDF), in Netstore 1999, October 1999. URL consultato il 27 January 2021.
  12. ^ Object Storage: What, How and Why?, NSF (Networking Storage Forum), SNIA (Storage Networking Industry Association), Live Webcast February 19, 2020
  13. ^ T10, https://www.t10.org/ftp/t10/document.99/99-315r0.pdf.
  14. ^ Object Based Storage: A Vision, slide presentation, Dave Anderson and Seagate Technology, October 13, 1999 https://www.t10.org/ftp/t10/document.99/99-341r0.pdf
  15. ^ computerweekly.com, https://www.computerweekly.com/feature/Unified-file-and-object-storage-The-best-of-both-worlds.
  16. ^ a b engineering.fb.com, https://engineering.fb.com/2009/04/30/core-data/needle-in-a-haystack-efficient-storage-of-billions-of-photos/. URL consultato il 5 October 2021.
  17. ^ storageconference.org, http://storageconference.org/2012/Presentations/M04.Dilger.pdf. URL consultato il 27 October 2013.
  18. ^ Copia archiviata, su multivu.com. URL consultato il 27 October 2013 (archiviato dall'url originale il 29 ottobre 2013).
  19. ^ emc.com, http://www.emc.com/about/news/press/us/2007/04182007-5028.htm. URL consultato il 3 November 2013.
  20. ^ techvalidate.com, http://www.techvalidate.com/portals/hitachi-content-platform-customers-with-more-than-1pb-of-data-stored. URL consultato il 19 September 2013.
  21. ^ Copia archiviata, in Infostor. URL consultato il 21 ottobre 2023 (archiviato dall'url originale il 7 dicembre 2021).
  22. ^ rethinkstorage.com, http://www.rethinkstorage.com/in-it-for-the-long-run-emcs-object-storage-leadership#.UyEzj9yllFI. URL consultato il 15 March 2014.
  23. ^ https://www.theregister.co.uk/2014/07/01/scalitys_ring_goes_faster/.
  24. ^ Datacenterknowledge.com, http://www.datacenterknowledge.com/archives/2013/01/18/facebook-builds-new-data-centers-for-cold-storage/.
  25. ^ Copia archiviata, su techexpectations.org. URL consultato il 23 May 2014 (archiviato dall'url originale il 22 maggio 2014).
  26. ^ Copia archiviata, su blog.oxygencloud.com. URL consultato il 27 October 2013 (archiviato dall'url originale il 29 settembre 2013).
  27. ^ Copia archiviata. URL consultato il 21 ottobre 2023 (archiviato dall'url originale il 19 gennaio 2022).
  28. ^ https://thenextweb.com/microsoft/2013/06/27/microsoft-our-cloud-powers-hundreds-of-millions/.
  29. ^ Copia archiviata. URL consultato il 21 ottobre 2023 (archiviato dall'url originale il 6 maggio 2014).
  30. ^ ISBN 978-1-4503-0977-6, http://sigops.org/sosp/sosp11/current/2011-Cascais/printable/11-calder.pdf.
  31. ^ Copia archiviata, su idc.com. URL consultato il 16 Feb 2020 (archiviato dall'url originale il 19 novembre 2021).
  32. ^ techstreet.com, http://www.techstreet.com/cgi-bin/detail?product_id=1204555. URL consultato l'8 November 2013.
  33. ^ techstreet.com, http://www.techstreet.com/products/1801667. URL consultato l'8 November 2013.
  34. ^ OpenStack Documentation, https://docs.openstack.org/developer/swift/api/object_api_v1_overview.html. URL consultato il 9 June 2017.

Voci correlate

[modifica | modifica wikitesto]
  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica