Che cos'è Cubbit DS3?

Intro

Cubbit DS3 è una piattaforma geo-distribuita di cloud object storage. A differenza dei fornitori di cloud centralizzati, Cubbit gira su una rete peer-to-peer (P2P) in cui ogni nodo è collegato a molti altri, con un hub centrale — il Coordinatore — che ottimizza la rete e la rende sempre più veloce ed efficiente nel tempo.

L'intelligenza del coordinatore e l'architettura distribuita rendono Cubbit unico nel suo genere: un cloud object storage geo-distribuito che offre sicurezza, scalabilità e convenienza di livello superiore.

I concetti chiave di Cubbit DS3 includono:

• Rete P2P: Questa sezione illustra le basi della rete Cubbit, i suoi vantaggi e il modo in cui opera per fornire una maggiore resilienza contro i guasti dei nodi e mantenere l'integrità dei dati.
• Architettura: Questa sezione approfondisce l'architettura di Cubbit DS3, descrivendo i suoi componenti e le loro interazioni e in quale maniera essi ottimizzano l'efficienza dello storage, la scalabilità e l'accessibilità.
• Object storage: Questa sezione descrive l'object storage utilizzato da Cubbit DS3, il quale consente di archiviare e gestire i dati in modo efficiente, scalabile e sicuro. Vengono inoltre illustrati i vantaggi dell'object storage rispetto ad altri metodi di archiviazione e le modalità di implementazione all'interno della piattaforma Cubbit.
• Ridondanza: Questa sezione illustra le caratteristiche di ridondanza di Cubbit DS3, spiegando come i dati vengono frammentati e archiviati su più nodi della rete P2P per garantire un'elevata disponibilità.
• Coordinatore: Questa sezione tratta il ruolo e le funzionalità del Coordinatore, l'hub centrale responsabile dell'ottimizzazione della rete, del miglioramento della tolleranza ai guasti e del recupero efficiente dei file.
• Recupero dei file: Questa sezione illustra il processo di recupero dei file in Cubbit DS3, spiegando come la piattaforma supporta il recupero dei file in maniera fluida ricostruendo i dati a partire dai frammenti disponibili, anche in caso di guasto di uno o più nodi.

Rete P2P

La rete P2P di Cubbit è il layer fisico che funge da spina dorsale di Cubbit. La rete, chiamata anche Swarm, è composta da più nodi che lavorano insieme per fornire agli utenti un cloud storage sicuro e scalabile.

I nodi possono essere fisici o virtuali. Un nodo fisico è una Cubbit Cell, un dispositivo autonomo che funge sia da unità di archiviazione dei dati che da nodo di relay, consentendo di archiviare e condividere i dati in modo sicuro sulla rete.

Per garantire la massima sicurezza, i dati degli utenti vengono criptati con AES-256 e suddivisi in pezzi, che vengono poi elaborati in più frammenti ridondanti tramite codici a correzione d'errore Reed-Solomon e diffusi in modo sicuro sulla rete attraverso canali peer-to-peer criptati end-to-end. Per questo motivo, nessuna Cubbit Cell archivia alcun file o oggetto nella sua interezza, nemmeno i file del suo proprietario. Al contrario, archivia frammenti criptati dei file di più persone.

Architettura

L'architettura di Cubbit DS3 ruota intorno a tre entità: l'Agente, il Coordinatore e l'SDK.

• L'Agente è un piccolo software che abilita un nodo di archiviazione Cubbit all'interno della rete peer-to-peer di Cubbit. Viene eseguito all'interno della Cubbit Cell.
• Il Coordinatore è un insieme di microservizi centralizzati progettati per coordinare e ottimizzare lo Swarm.
• Il Cubbit SDK è una raccolta di strumenti e risorse che gli sviluppatori possono utilizzare per creare applicazioni software su Cubbit. Interagisce con l'Agente, il Coordinatore e il Gateway S3 di Cubbit per abilitare l'object storage nel cloud di Cubbit compatibile con S3.

Object storage

In informatica, il termine "oggetto" si riferisce a dati binari, spesso noti come BLOB (Binary Large OBject). I BLOB possono comprendere immagini, file audio, fogli di calcolo e persino codice eseguibile binario.

Con object storage ci si riferisce invece a una piattaforma che fornisce strumenti specializzati per l'archiviazione, il recupero e la localizzazione dei BLOB. In termini di applicazioni pratiche, l'object storage è un tipo di architettura di archiviazione dei dati progettata per grandi quantità di dati non strutturati, come video, file audio, immagini e documenti. Organizza gli oggetti in bucket, simili alle cartelle di un file system; ogni bucket può contenere un numero illimitato di oggetti. A differenza dei metodi di archiviazione tradizionale file storage e block storage, l'object storage non utilizza un file system gerarchico. Si tratta invece di uno spazio di indirizzi piatto in cui i dati vengono memorizzati come oggetti contenenti dati grezzi, metadati e un identificatore univoco.

L'object storage è superiore a file storage e block storage per diversi aspetti:

• Sicurezza: l'object storage offre livelli più elevati di durabilità dei dati replicandoli su più nodi e memorizzandoli in uno spazio di indirizzi piatto, riducendo al minimo il rischio di perdita dei dati in caso di guasto di un nodo.
• Scalabilità: l'object storage è progettato per gestire grandi quantità di dati non strutturati ad alte prestazioni, la qual cosa lo rende ideale per archiviare e accedere a grandi quantità di file, immagini, video e altri tipi di dati.
• Economicità: l'object storage elimina la necessità di un costoso tiering dei dati, rendendolo più conveniente rispetto ai modelli di archiviazione tradizionali file storage e block storage.

File storage vs block storage vs object storage​

I metodi di archiviazione si sono evoluti nel corso degli anni per adattarsi alla natura mutevole dei dati. I modelli di archiviazione file storage e block storage sono adatti ai dati strutturati, ma poiché le organizzazioni devono affrontare volumi crescenti di dati non strutturati, l'object storage è emerso come soluzione superiore. File storage organizza i dati all'interno di cartelle e si basa su una gerarchia di directory e subdirectory. Funziona bene per i dati di dimensione ridotta e facilmente organizzabili, ma con l'aumentare del numero di file questo modello diventa macchinoso e richiede molto tempo. Block storage suddivide un file in blocchi di uguali dimensioni e li archivia separatamente, offrendo efficienza e prestazioni migliori per le applicazioni aziendali critiche e i database transazionali. L'object storage, invece, tratta gli oggetti come unità discrete di dati memorizzati in un ambiente strutturalmente piatto in cui ogni oggetto include dati grezzi, metadati e un identificatore unico. Tale modello offre una capacità di archiviazione economica per i dati non strutturati ed è ideale per i dati che cambiano raramente o mai. Inoltre, fornisce metadati più descrittivi rispetto a file storage, consentendo la personalizzazione e analisi ulteriori.

Cubbit DS3

Cubbit DS3, abbreviazione di Distributed Simple Storage Service, è una piattaforma di object storage geo-distribuita e compatibile con S3. I suoi bucket hanno funzionalità paragonabili a quelle dei bucket AWS S3 e forniscono soluzioni di archiviazione affidabili e scalabili per i dati non strutturati. Inoltre, la natura geo-distribuita della soluzione Cubbit DS3 offre agli utenti una maggiore sicurezza ed economicità rispetto alle tradizionali soluzioni di cloud storage centralizzate. Essendo compatibile con S3, Cubbit può offrire soluzioni all'avanguardia per la protezione, la distribuzione e il recupero dei dati, quali:

• Object Locking
• Bucket Versioning
• Multipart Upload

Casi d'uso

Backup

Cubbit DS3 è la soluzione ideale per le organizzazioni che desiderano automatizzare i propri backup off-site in modo rapido, sicuro e immutabile. La piattaforma è compatibile con Veeam o con qualsiasi altro client S3, il che semplifica l'archiviazione dei backup su Cubbit e la protezione dei dati da eventuali disastri. Grazie alle sue funzioni avanzate di gestione dei dati, gli utenti possono facilmente recuperare i propri dati in base alle necessità in modo economico sfruttando la compatibilità con Cubbit S3. L'infrastruttura di rete geo-distribuita di Cubbit offre storage scalabile per grandi quantità di dati senza sacrificare le prestazioni. La sicurezza dei dati è una priorità assoluta: la crittografia a più livelli e le solide opzioni di disaster recovery assicurano che i dati siano sempre protetti.

Hybrid Cloud

Con Cubbit DS3 e la giusta strategia di hybrid cloud puoi estendere virtualmente i tuoi NAS e le tue macchine virtuali senza interrompere il tuo flusso di lavoro, garantendo un rapido ripristino dei cold backup e collaborando localmente in modo sicuro. Se hai a che fare con enormi dataset o applicazioni che richiedono molte risorse, Cubbit DS3 può aiutarti a realizzare una strategia di hybrid cloud semplice, sicura e ad alte prestazioni, liberandoti dalle limitazioni della larghezza di banda.

Cloud-to-cloud

Con Cubbit DS3 puoi automatizzare i processi di scripting e migrare senza sforzo enormi quantità di dati nel pieno rispetto delle normative. Con un semplice cambio di endpoint e la connessione a Cubbit tramite rclone/AWS CLI puoi implementare una strategia multi-cloud, diversificare il rischio e fornire ai tuoi clienti una exit strategy sicura che soddisfi i requisiti della GDPR.

Hybrid backup

Grazie alla sincronizzazione bidirezionale tra il NAS e lo storage di oggetti, Cubbit DS3 ti consente di pianificare i backup job e proteggere i tuoi dati da potenziali minacce come i ransomware e i disastri naturali. Utilizzando la tecnologia di deduplicazione puoi comprimere i dati, ridurre al minimo l'uso della banda e ridurre i tempi di trasferimento. L'implementazione di un piano di backup completo ti garantisce la tranquillità di sapere che i tuoi dati sono al sicuro e facilmente accessibili in caso di emergenza.

Applicazioni Cloud-native

Con le API Cubbit DS3 puoi semplificare lo sviluppo delle applicazioni e concentrarti sulla programmazione senza preoccuparti dell'archiviazione dei dati. Cubbit DS3 offre una soluzione altamente scalabile, flessibile ed economica e pertanto può fungere da archivio dati persistente per la creazione o la transizione verso applicazioni cloud-native. Ti basta cambiare l'endpoint e fare deployment sull'object storage compatibile con S3 di Cubbit per ottenere risultati immediati.

Archiviazione e distribuzione di contenuti multimediali

Cubbit DS3 è stato progettato per essere altamente conveniente per l'archiviazione e la distribuzione di file multimediali di grandi dimensioni quali musica, video, immagini e oggetti più complessi. Grazie alle sue potenti funzionalità di distribuzione globale, le organizzazioni possono distribuire rapidamente e facilmente i loro contenuti multimediali a un pubblico globale, riducendo i costi e migliorando l'esperienza degli utenti. Cubbit DS3 è perfetto per le organizzazioni nell'industria dei media con esigenze di archiviazione dati in rapida crescita poiché garantisce che le loro soluzioni di archiviazione siano al passo con le loro esigenze aziendali.

Big data analytics

Cubbit DS3 può essere utilizzato per archiviare grandi quantità di dati di qualsiasi tipo, compresi i big data. Con le applicazioni di terze parti compatibili con S3, le organizzazioni possono eseguire analisi dei big data e ottenere preziose informazioni sul comportamento dei clienti, sulle operazioni e sulle tendenze del mercato. I dati possono essere archiviati nella loro forma grezza, consentendo una certa flessibilità nell'analizzarli e nel ricavare informazioni significative. Questo può aiutare le aziende a prendere decisioni più informate e a promuovere la crescita senza doversi preoccupare dei limiti dei sistemi di archiviazione tradizionali.

Internet delle cose

Cubbit DS3 è progettato per gestire grandi quantità di dati machine-to-machine in modo efficiente ed economico. Essendo compatibile con S3, Cubbit DS3 può essere sfruttato attraverso applicazioni di terze parti per supportare l'intelligenza artificiale e le applicazioni di analisi avanzate che trasformano i dati generati dai dispositivi IoT in informazioni utili. Con Cubbit DS3, le organizzazioni IoT-first possono ottimizzare i processi di gestione dei dati, ridurre i costi e migliorare l'accuratezza dei dati.

Ridondanza

Quando si parla di object storage geo-distribuito, è fondamentale assicurare che i nodi rimangano online. Questo garantirà i più elevati standard di durabilità (99,999999999%) e disponibilità (99,95%).

A tal fine, molte aziende che offrono un cloud centralizzato creano molteplici copie dei dati attraverso strategie come RAID o la replica dei bucket. Ciò consente di diversificare il rischio di downtime, ma comporta comunque la saturazione della larghezza di banda e della capacità di storage. Inoltre, nel caso del RAID, i dati sono vulnerabili a disastri locali come incendi e blackout.

Cubbit, invece, sfrutta la ridondanza offerta dall'algoritmo di correzione degli errori Reed-Solomon. Questo garantisce 99,999999999% di durabilità e una disponibilità del 99,95% senza sacrifici significativi in termini di performance e capacità di archiviazione — e garantendo al contempo la geo-distribuzione off-site.

Questo algoritmo, applicato a un campo di Galois di 256 elementi ($GF(28)$), trasforma un file in $n$ shards e create ulteriori $k$ shard di ridondanza, per un totale di $n + k$ shards. Qualsiasi $n$ di questi shard è sufficiente per recuperare l'intero oggetto o file.

Attualmente, $n$ e $k$ sono dimensionati a:

• $n = 20$
• $n + k = 60$

Questa scelta consente ai payload di rimanere stabili sulla rete con un rapporto di memorizzazione di appena 3 ($\frac{n + k}{n}$) rispetto alla dimensione del payload originale — ottenendo al contempo prestazioni più elevate e medesima (o addirittura superiore) durabilità rispetto alle strategie RAID e di replica dei bucket.

Anche se la probabilità di perdere un file con l'algoritmo Reed-Solomon è minima, esiste comunque la possibilità che un numero significativo di agent dello stesso pool vada offline nello stesso momento (ad esempio a causa di blackout, disastri locali o incendi).

Euristica sulla selezione del pool

Per prevenire la criticità indicata nell'ultimo paragrafo della sezione precedente, il Coordinator di Cubbit seleziona i nodi in base a questi 5 criteri:

1. Uptime: se l'uptime di un peer è elevato, questo sarà più affidabile e disponibile a ricevere shard.
2. Geolocalizzazione: c'è un bilanciamento tra la scelta di peer vicini (con l'obiettivo di ottimizzare le prestazioni) e lontani (con l'obiettivo di diversificare il rischio di downtime del pool a causa di blackout e disastri locali).
3. Carico medio: più shard gestisce un peer, maggiore è la probabilità di perdere un payload quando un peer va offline. Per questo motivo, un buon pool non dovrebbe gestire troppi shard correlati tra loro.
4. Larghezza di banda: la larghezza di banda dei peer all'interno del pool deve essere equilibrata per fornire una velocità di trasferimento uniforme a tutti gli utenti.
5. Storico dei peer: se gli utenti spengono sistematicamente alcuni nodi durante la notte, ottengono un rank basso. Di conseguenza, altri peer verranno scelti come più affidabili.

Oltre alla selezione dei peer, Cubbit ha anche una strategia di file recovery in crowdsourcing che sfrutta il potere dei nodi peer-to-peer. Puoi consultare la documentazione sul recupero dei file.

Coordinator

Il Coordinator è l'intelligenza centrale di Cubbit, in carica di:

• Garantire la sicurezza delle transazioni.
• Facilitare le comunicazioni tra gli Agent.
• Ottimizzare la distribuzione del payload sulla rete.
• Tenere traccia della posizione dei file e dell'uptime tramite i metadati.
• Attivare procedure di file recovery nello Swarm.

Il Coordinator è crittograficamente cieco: conosce solo la posizione e i metadati funzionali degli oggetti e dei file. Allo stesso tempo, i payload sono salvati sui nodi della rete garantendo alte prestazioni.

Il Coordinator di Cubbit ha un ruolo chiave nella distribuzione dei dati, nella selezione dei peer e nelle procedure di recovery.

Il ruolo del Coordinator nella distribuzione dei file e nella selezione dei peer

Ogni file salvato su Cubbit viene crittografato con AES-256, frammentato in chunk, ridondato in $n + k$ shard (utilizzando un algoritmo chiamato Reed-Solomon) e geo-distribuito sulla rete peer-to-peer di nodi. Il file originale può essere ricostruito da ogni $n$ shards delle $n + k$ originali.

Dopo aver applicato l'algoritmo per la correzione degli errori Reed-Solomon, il Coordinator determina gli Agent più adatti a ospitare i frammenti di shard crittografati. Ciascuno degli $n + k$ shard è memorizzato su un Agent differente.

A tal fine, il Coordinator esegue algoritmi di machine learning per nullificare la probabilità di perdere i file e garantire una prestazione stabile della rete. In altre parole, il Coordinator distribuisce i pezzi il più lontano possibile, minimizzando allo stesso tempo la latenza di rete e altri fattori (e.g., utilizzo della larghezza di banda, ottimizzazione dello storage, ecc.)

Come il Coordinator attiva la procedura di recovery

Per scaricare un file dallo Swarm è sufficiente un sottoinsieme $n$ degli $n + k$ shard.

Per garantire i più elevati standard di durabilità e disponibilità, il Coordinator monitora lo stato di uptime di ogni Cubbit Cell, attivando una procedura di recovery quando il numero totale di shard online oltrepassa una certa soglia, ovvero $n +\frac{k}{2}$.

Se più della metà di $k$ Agent va offline, il Coordinator avverte gli Agent rimanenti di contattare ulteriori nodi per ripristinare al 100% il numero di shard online.

Recupero dei file

Anche se la probabilità di perdere un file è minima, esiste comunque la possibilità che un numero significativo di peer dello stesso pool vada offline contemporaneamente (ad esempio a causa di blackout, disastri locali o incendi).

Per garantire i più elevati standard di durabilità (99,999999999%) e disponibilità (99,95%), Cubbit impiega 2 procedure:

1. Euristica sulla selezione dei peer: puoi scoprire i 5 criteri utilizzati per la selezione dei peer nella sezione Ridondanza.
2. Strategia di recovery: la approfondiamo qui di seguito.

Strategia di recovery

Se, dopo una serie di disconnessioni cumulative, la ridondanza di un file (cioè il numero di shard online $d$ che superano $n$) è inferiore a una soglia di sicurezza $d_0$ (con $0 < d_0 < k$), il Coordinator attiva una procedura di recovery (chiamata "strategia pigra di recovery"):

1. Il server identifica i ($k - d$) membri alternativi del pool che sostituiranno i peer che sono andati offline.
2. Il coordinatore ordina a un nodo di recuperare $n$ shard dal pool danneggiato.
3. Il nodo scelto recupera $n$ frammenti e inverte Reed Solomon per ottenere un pezzo crittografato (si noti che non è necessario conoscere la chiave AES usata per crittografare il file per invertire il processo di ridondanza).
4. Il nodo ridistribuisce i frammenti recuperati ai ($k - d$) nuovi membri del pool.