Mi permetto di fare qualche speculazione personale, sperando che eventuali copioni abbiano la bontà di citare la fonte.
Un anno fa commentavo l'annuncio della tecnologia "Kinetic" della Seagate: cioè hard disk con interfaccia ethernet, che accettano operazioni stile database.
Non più la lettura/scrittura di settori (col sistema operativo che organizza files, directories e permessi), ma direttamente le read/write/delete di coppie di valori
key/value (su socket non necessariamente criptato).
Un software potrà accedere ai dischi semplicemente comandando "aggiorna questa
key associandola questo
value, leggi il
value della tal
key", facendo esclusivamente operazioni su una connessione di rete.
Un filesystem sarà perciò realizzato usando la
key per filename e attributi/permessi, e il
value per il contenuto del file.
Un database sarà realizzato usando la
key per indicare "database X, tabella Y, campo Z", e il
value per il contenuto del campo.
In entrambi i casi non c'è bisogno che il sistema operativo supporti un "filesystem": basta leggere/scrivere/cancellare gli oggetti
key/value direttamente su una connessione ethernet. Una libreria software potrà occuparsi della gestione dei permessi (per esempio gli "user" abilitati su una determinata "tabella") mentre il firmware del disco prevederà una modalità "amministratore" per limitare/verificare gli accessi e una modalità di comunicazione tra i dischi per scambiarsi i dati (bilanciamento degli spazi occupati).
I
limiti imposti dalla Seagate mi fanno capire che i progettisti sanno bene di aver scoperto l'acqua calda: basterebbe un qualunque computerino per emulare il protocollo Kinetic con dischi normali o per aggirarne i limiti o addirittura per inserirsi "a fianco" di un parco di dischi Kinetic. La Seagate intende vendere una soluzione già completa con tutti i vantaggi commerciali (creare o far crescere lo
storage senza dover aggiungere interfacce, semplificare i carichi di lavoro dei server database, ecc).
I limiti imposti alla prima generazione di dischi Kinetic sono:
- key di "4 kilobytes" (ossia la grandezza di un singolo settore fisico dei nuovi dischi)
- value di "un megabyte" (cioè 255 o 256 settori fisici)
- due interfacce ethernet da un gigabit - presumibilmente una "administrator" e una "user"
- hardware: un disco da 4 tera a 5900 giri/minuto formato 3.5", il connettore è come un "SAS" ma con i segnali cambiati, e richiede ovviamente le tensioni 5V e 12V.
Interfacce
Anche se la presentazione dice che i dischi hanno due porte gigabit "per comunicare tra loro", mi sembrerebbe stupido non dare ad un "amministratore" la possibilità di accedere al
singolo disco separatamente dal traffico di rete. Pertanto in un rack metterei una ventina di dischi su uno switch a 24 porte (una o più delle quali connesse ai miei server), e un altro switch a 24 porte (di cui una singola porta connessa alla consolle remota, isolando le porte "administrator" dai server). Lo switch lato server potrebbe anche essere un 10 gigabit. Ogni disco avrà la porta "utenza" connessa al primo switch, e la porta "amministrazione" connessa al secondo.
Se non è così, allora devo ipotizzare che i dischi sarebbero collegati "a cascata" (una porta ethernet va al "precedente" e una al "successivo", tranne il primo e l'ultimo disco della catena che avrebbero rispettivamente una porta "amministratore" e una "utente") ma questo limiterebbe il throughput
totale al gigabit della singola porta "user". Inoltre, in caso di guasto di un disco (o di una delle sue porte), occorrerebbe intervenire manualmente a sostituire e riconfigurare prima di poter riavviare.
Queste considerazioni potrebbero cadere solo per motivi commerciali (la Seagate potrebbe aver pianificato la "prima generazione" dedicata a piccole installazioni in cui l'avere la "catena" e il limite di un gigabit di throughput sarebbe tutto sommato accettabile, diciamo fino a una dozzina di dischi, e magari tirar fuori successivamente la "seconda generazione" prevista per sommare le performance dei singoli e magari con le porte già a 10Gbit).
Key/value
La dimensione della
key è abbastanza indovinata: è un intero settore fisico (4096 bytes, o al limite 4095 per riservarsi un byte di
flags - dopotutto nel gergo commerciale "4000" o "4095" o "4096 bytes" sono
sempre "4k"). Per agevolare la ricerca e l'ordinamento (suppongo che il firmware del disco ordini le
key con un
RB-tree e i
value vengano "deframmentati" in background) basterà porre a zero i byte non usati della
key prima di scriverla.
La
value di un megabyte copre gran parte degli utilizzi tipici dell'internet (pagine html, foto, status, ecc.) mentre eventuali dati più lunghi possono essere simulati allocando più
key (aggiungendo 001, 002...). Chi ha bisogno di storage per grossi file probabilmente non vorrà usare degli hard disk.
Le
key probabilmente saranno in numero prefissato (suppongo una potenza di due per motivi di bilanciamento), proprio come gli
inode di un filesystem Unix. Il firmware potrebbe anche permettere di raddoppiare o dimezzare dinamicamente il numero delle
key o riversare sui dischi "vicini" le
key/value in eccesso (e perfino "travasare" il contenuto di un disco prossimo alla fine del suo ciclo di vita sparpagliandolo sugli altri ancora in salute): tanto di cappello ai firmwaristi Seagate se ci sono riusciti a farlo in modo trasparente, ma secondo me la prima generazione di dischi avrà un numero fisso di
key.
Se il numero di
key è
n, allora con un RB-tree le operazioni di ricerca, inserimento e cancellazione di una
key (e del corrispondente
value) saranno nel peggiore dei casi tutte dell'ordine di
O(ln n).
API
Le Application Program Interfaces dei dischi Kinetic sono riassunte dalla Seagate in sei categorie:
- accesso key/value (scrivi un value associato ad una key; leggi il value di una data key oppure "not found"; cancella una coppia key/value);
- iterazioni sulle key (cerca una key che abbia questo pattern o valore, oppure cerca un value che cominci con questo pattern: come la LIKE dell'SQL; suppongo che la ricerca all'interno delle value non sia implementata... che fai, scandisci un intero disco da quattro tera?)
- gestione accessi da "terze parti" (ossia da altri software dello stesso server o meno): il firmware implementerà una serie di token per le singole operazioni definite dalle API (magari addirittura stampigliate sulla confezione)... token utente lettura/scrittura, token sola lettura, token relativa alle sole key che iniziano per XYZ...
- cluster management: parolone commerciale che può significare tutto e niente; può significare il bilanciamento automatico tra i vari dischi dello spazio utilizzato e della quantità di key e dallo stato di salute dei dischi (tanto di cappello!) oppure solo la configurazione iniziale (concettualmente "formattazione") per definire come si intende usare la catena, e la richiesta esplicita di togliere un disco dalla catena (forzando manualmente il bilanciamento);
- drive management: questo evidentemente sarà il nome commerciale dello SMART-monitoring;
- security management: riguarderà senza dubbio le password di amministrazione dei dischi (non vorrete mica fare cluster management non appena conoscete l'indirizzo di rete del disco?) e la definizione di quali indirizzi IP sono autorizzati a utilizzare i dischi e a che titolo.
Paranoie sullo spionaggio
Tutte le periferiche "intelligenti" (che abbiano cioè almeno un processorino a bordo) sono virtualmente taroccabili - non tanto dagli hacker, quanto dai produttori. Negli hard disk il firmware è un vero e proprio
sistema operativo che ha accesso ai dati che l'utente legge e scrive.
Con la serie Kinetic si pone un nuovo problema: i dischi sono su rete locale, non più sulla propria interfaccia dedicata. Per accedere fisicamente al contenuto dei dischi non c'è più bisogno di smontare il disco dalla macchina e installarlo su un'altra macchina dotata dello stesso controller: è sufficiente collegarsi sulla stessa LAN gigabit dove è connesso il disco.
La LAN può anche essere protettissima, ma lo switch su cui sono attaccati i dischi? E quanti switch/router attraversa la connessione ethernet fino al server che li usa? Un rack dischi spento o con un disco in meno si nota subito anche da remoto; uno switch con un cavo in più (aggiunto in un attimo e senza spegnere nulla) non lo nota nessuno.
Qualcuno crederà di risolvere tutto crittografando i dati prima di scriverli sul disco: questo non solo aumenta il carico di lavoro sul server ma castra le funzionalità dei dischi (una key crittografata non è ricercabile/ordinabile/accorciabile: saranno sempre 4096 bytes apparentemente casuali).
Inoltre, ammesso e non concesso che i dischi rispondano solo a determinate token da determinati indirizzi di rete e che siano tutti in una LAN isolata dall'internet... chi può garantire che i dischi non contengano backdoor o vulnerabilità sfruttabili da un malware installato sul server o addirittura da un utente remoto che abbia accesso a tale LAN? (e quando poi comincia ad infilarsi in mezzo il cloud? non a caso la Seagate ha comprato la Xyratex pagandola un fiotto di milioni...)
Parlo così non solo perché mi sono più volte attaccato a switch che
di default avevano tutte le porte attivate e nessun filtro (l'incompetenza e la faciloneria sono il principale vettore di guai informatici) ma anche perché diversi anni fa lessi gli articoli del
l'autrice di Qubes OS che dimostrò che si può installare una
backdoor perfino in un microprocessore: è sufficiente che abbia una EEPROM in cui salvare un flag che resista all'accensione/spegnimento, in modo da non rendere deterministica (e quindi facilmente scopribile) la
backdoor creata dal produttore.
Emulazione
Con poca spesa si possono comprare uno switch gigabit da 16 porte, una dozzina di dischi USB da 2.5" e una dozzina di
BeagleBone. Una fungerà da "master" e bilancerà il carico sulle altre (e i 512Mb RAM di ognuna fungeranno da cache), comandando trasferimenti tra i dischi o verso l'utente. L'RB-tree delle
key sarà un singolo file statico (per l'accesso ad una
key basterà una
seek) e i
value saranno dei file su disco numerati in sequenza. Magari si può implementare anche l'alta affidabilità permettendo che in caso di crash del master, uno degli altri peer possa diventare master riconosciuto. Probabilmente un progetto da non oltre 15-20.000 righe di codice C che non avrà neppure bisogno di girare come root. L'esperimento ovviamente ha senso solo per lo storage soggetto a particolari carichi di lavoro (quando si ha una foresta di siti web e database: è probabile che non valga la pena se ci sono meno di un migliaio di operazioni al secondo).
Post
Insomma, un manufatto umano zeppo di strumentazione scientifica atterra con precisione su una cometa a mezzo miliardo di chilometri di distanza (incidentalmente dotata di forma strana e gravità quasi inesistente), e una tizia cosa fa?
