giovedì dic 18, 2008

L'architettura applicativa del servizio blogs.sun.com

Questo white paper illustra l'architettura applicativa del servizio blogs.sun.com, partendo dai dati di accesso ed i commenti di chi lo gestisce:

In particolare prodotti utilizzati sono:

martedì apr 15, 2008

Abbiamo ancora bisogno delle directory nei file system?

Riguardando il video sulla rivoluzione/evoluzione dell'informazione, mi viene il dubbio che il concetto stesso di directory, all'interno di un file system, sia "superato".

Fin dall'origine dell'informatica domestica siamo stati abituati a riporre i nostri documenti (file) all'interno di una struttura gerarchica (directory), con il risultato che spesso, oggi, mi ritrovo lo stesso file salvato più volte, in differenti directory, proprio perché il documento non è associabile solo ad una sola categoria (directory), ma ad esempio a due o tre contemporaneamente, ed io utilizzo ogni volta quella che in quel momento ritengo la più "importante". Viceversa, quando ricerco un file, rischio di cercarlo nella directory sbagliata.

Una evoluzione simile a questa vi è già stata con la gestione dei bookmark, che dalla classica struttura gerarchica nei menu dei browser sono passati ad un catalogo online gestito associando ad ogni link una o più "etichette" (tag), come ad esempio permette di fare il sito del.icio.us. Quando la gestione dei tag è condivisa tra più utenti, in un modello di social networking, si usa il termine folksonomy. Con questo modello associare più di una etichetta (tag) ad un link equivale, nella pratica, a riporlo allo stesso tempo in più di un una categoria (directory), ma senza avere una effettiva duplicazione del dato.

Lo stesso approccio di indicizzazione basato su tag può essere utilizzato da un file system che (senza entrare in un discorso più complesso di semantic file system) può catalogare i file al proprio interno non in base alle directory, ma in base ai tag ad essi associati. In tal caso si può definirlo un "tagged file system".

Ovviamente si aprono un certo numero di dubbi su come un tagged file system può essere implementato:

  • Per identificare in modo univoco un file in un tagged file system (privo di directory), esiste un insieme minimo di tag da indicare assieme al nome del file? O si devono (dopo una opportuna ricerca) utilizzare sempre tutti i tag?
  • Possono esserci due file con lo stesso nome ed un sottoinsieme di tag in comune? Se sì, nel caso di un accesso che identifica il file con tale nome ed un insieme di tag uguale al sottoinsieme di tag in comune, come gestire il possibile conflitto? Indicando, con un codice di ritorno, che c'è bisogno di più informazioni per trovare il file corretto?
  • E' possibile eliminare completamente il concetto di directory, o conviene comunque affiancare una struttura gerarchica ai tag?

Per maggiore chiarezza provo a riportare un esempio. Quando in una applicazione, al termine delle modifiche, si deve salvare un file in un tagged file system, le informazioni da indicare sono:

  • il file system (potrebbe esserci un file system separato per ogni utente, con una flessibilità nel creare file system simile a quella di ZFS)
  • il nome del file
  • i tag che descrivono il file (alcuni tag potrebbero indicare il tipo di file, al posto dell'estensione nel nome del file stesso)

I tag sostituiscono in questo esempio l'uso delle directory. I tag già usati possono essere suggeriti, come nel modello folksonomy, in modo da evitarne la proliferazione.

Usando dei tag con un formato del tipo "parametro:valore" si possono aggiungere con flessibilità dei metadati che vanno oltre il semplice tagging. Si deve valutare se l'aumento nella complessità controbilancia le potenzialità espressive di una sintassi di questo genere.

Credo sia chiaro che in questo ambito ci sia molto spazio per l'analisi e la ricerca. Uno dei passi necessari è senz'altro la definizione di un insieme standard di API per l'accesso ai file che vada oltre l'interfaccia standard POSIX. Potrebbe essere utile il lavoro in corso sullo standard XAM. Si può per semplicità valutare la possibilità di costruire il modello a tag sopra un file system normale, ad esempio ricavando la directory in cui collocare un file a partire dai tag ad esso associati. Ogni idea è la benvenuta.

lunedì apr 14, 2008

ZFS, il File System del Futuro

Per approfondire le potenzialità di ZFS ecco alcune slide che ne descrivono ad alto livello le principali funzionalità:

mercoledì mar 19, 2008

La Storia dei File System... fino a ZFS!

Ecco un ottimo articolo su Ars Technica che descrive l'evoluzione del concetto di "file system" dalle origini (con IBM, DEC, il CP/M, ecc.) fino ai nostri giorni.

Oggi il file system è spesso ritenuto una funzionalità base, non più rilevante nelle scelte tecnologiche, ma quasi una "commodity" che è parte di un sistema operativo e non viene messa in discussione. Ciò è probabilmente il risultato di almeno 20 anni di sviluppo incrementale in questa area, ovvero di un tipo di sviluppo che non ha introdotto innovazioni "rivoluzionarie", ma ha aggiunto funzionalità "poco a poco". D'altronde lo spazio che un file system deve gestire continua a crescere con legge esponenziale e alcune caratteristiche devono necessariamente essere ripensate. Provare a ricominciare da zero nell'immaginare come implementare un file system è stato l'approccio alla base della nascita di ZFS.

venerdì ott 12, 2007

Che cos'è ZFS?

...ecco una risposta breve ma piuttosto esaustiva.

ZFS è un nuovo tipo di file system che fornisce una semplice amministrazione, una approccio transazionale, una integrità del dato "end-to-end" e una immensa scalabilità (128-bit). ZFS non è un miglioramento "incrementale" alla tecnologia esistente, ma è un nuovo approccio alla gestione dei dati creato eliminando alcune assunzioni di base che risalevano a 20 anni fa.

ZFS è basato su un modello di "storage pool" che elimina completamente il concetto di "volumi" ed i problemi associati di partizionamento, provisioning e bilanciamento del carico sui device fisici. Migliaia di file system possono prelevare lo spazio da uno Storage Pool comune e ciascuno di essi consumerà solamente lo spazio di cui ha bisogno. In questo modo la banda di I/O combinata di tutti i device nel pool è disponibile per tutti i file system, in ogni momento. Per regolare l'accesso condiviso ad uno Storage Pool ogni file system può avere associati dei parametri di quota (massimo spazio visibile all'interno del pool) e reservation (spazio del pool dedicato ad un file system e non visibile agli altri). Tali parametri sono logici e possono istantaneamente essere cambiati in qualsiasi momento.

Tutte le operazioni sono transazioni "copy-on-write", in questo modo lo stato dei dati su disco è sempre valido. Non serve (e non esiste) un "fsck" per un ZFS. Ogni blocco ha un checksum per prevenire una corruzione silente dei dati ed il dato stesso è riparato in automatico se si trova in un pool in configurazione mirror o RAID. Se una copia è danneggiata, ZFS se ne accorge e usa un'altra copia per riparla. ZFS introduce un nuovo modello di replicazione dei dati chiamato RAID-Z. E' simile al RAID-5, ma usa uno striping a dimensione variabile che, assieme al "copy-on-write", elimina il RAID-5 "write hole" (la corruzione dovuta ad una perdita di corrente tra l'aggiornamento dei dati e della parità). Tutte le scritture RAID-Z sono effettuate in striping. ZFS implementa inoltre una pipeline per le richieste di I/O, con un concetto simile a quello dei processori (CPU). La pipeline effettua lo scheduling più performante per le richieste di I/O, cambiando l'ordine delle operazioni all'interno di una transazione "copy-on-write".

Sfruttando il "copy-on-write" ZFS permette di creare rapidamente un numero illimitato di snapshot (read-only) e cloni (read-write) di un file system. Le funzionalità di backup e restore di ZFS sono basate proprio sugli snapshot. Ogni snapshot può generare un backup completo, ogni coppia di snapshot può produrre un backup incrementale. I backup incrementali possono essere utilizzati per implementare una architettura di data replication, ad esempio trasmettendo un "incremento" ogni 10 secondi.

ZFS permette di attivare su base file system la compressione trasparente dei dati. Oltre a ridurre il consumo di spazio, la compressione riduce anche il numero di richieste di I/O. Per questo motivo si è verificato che attivando la compressione con particolari workload si ottiene anche un beneficio prestazionale.

Oltre ai file system, uno Storage Pool ZFS può fornire dei volumi alle applicazioni che necessitano di una semantica di tipo raw-device. I volumi ZFS possono per esempio essere utilizzati come device di swap. Ed attivando la compressione su un volume di swap, si ottiene di aver compresso la memoria virtuale di un sistema. A partire dall'ultimo aggiornamento di Solaris 10 (8/07) i volumi ZFS possono essere esportati via rete tramite iSCSI

Ecco alcuni utili puntatori per maggiori informazioni:

venerdì set 21, 2007

GlassFish v2 (aka SJS Application Server 9.1)

E' disponibile GlassFish v2 (aka SJS Application Server 9.1), la nuova versione dell'application server di riferimento per la piattaforma Java Enterprise Edition (EE).

Alcune tra le nuove funzionalità :

  • Clustering ed alta affidabilita (HA), sia attraverso repliche dei dati in memoria tra i nodi che tramite HADB
  • Performance ai vertici del benchmark di mercato SPECjAppServer2004
  • Migliori performance per i Web Service con il framework Metro
  • Interoperabilità con l'ambiente .Net (ad esempio un foglio di calcolo Excel può avere delle celle il cui contenuto è aggiornato dinamicamente a partire da un server GlassFish)
  • Supporto per l'ambiente di sviluppo NetBeans (sia la versione 5.5.1 che la 6 ad oggi in beta), ma anche per Eclipse 3.3, MyEclipse, IDEA, ecc.
  • Supporto per tecnologie AJAX nel Web Tier (jMaki e JSF)
  • Supporto per linguaggi e ambienti di scripting come jRuby e Phobos
  • Console e amministrazione centralizzata
  • ...

Con GlassFish non si deve scegliere tra software open source e di classe enterprise: sono disponibili tutte e due le versioni!

mercoledì set 12, 2007

Sun annuncia l'accordo per acquisire Cluster File Systems, Inc. (incluso Lustre)

Sun ha annunciato oggi l'accordo per acquisire la proprietà intellettuale e gli asset di business di Cluster File Systems, Inc., incluso il file system parallelo Lustre. Sun intende aggiungere supporto e funzionalità per Lustre su Linux, Solaris ed in ambito multi-vendor. Come già annunciato a luglio di quest'anno, Sun intende utilizzare Lustre su ZFS, il file system open-source incluso in Solaris, creando una piattaforma di storage virtualization con aspetti molto interessanti sia dal punto di vista della potenzialità che delle funzionalità.

La press release ufficiale contiene maggiori dettagli.

About

Un diario digitale sui miei interessi: Internet, Solaris, Java, Fotografia, ecc.

Search

Archives
« aprile 2014
lunmarmergiovensabdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today