giovedì dic 11, 2008

Dopo l'annuncio ufficiale di OpenSolaris 2008.11...

...non resta che scaricarlo ed installarlo, su un sistema fisico o (se preferite) virtuale. ;-)

Ecco alcuni video che illustrano:

Le principali nuove funzionalità

Una demo di Time Slider (già discusso qui)

Il punto di vista di Intel...

...E quello di AMD


Un'altra interessante presentazione delle novità presenti in questa release è quella di Roman Strobl che potete trovare qui.

mercoledì dic 10, 2008

Innovation @ Sun to reduce your TCO

Last week I was asked by a colleague to prepare a (nearly) "one hour presentation" to show to our customers how Sun is continuing to innovate on its technologies and products to provide solutions that can give them benefits as reducing the overall TCO of an IT infrastructure. Actually a lot of different ideas came to my mind and I was wandering how may IT companies could answer with such a wide portfolio to that question.

Now I am sharing the outcome of that request here, the main topics are:

  • the CMT/CoolThreads systems (available as servers and blades)
  • the new Open Storage appliances based on OpenSolaris and ZFS
  • OpenSolaris as the Developer's Desktop (with Time Slider to go back in time!)
  • the xVM product line (VirtualBox, Server, Ops Center and VDI) for Virtualization and Manageme
By the way, this is my first post in english on this blog, but I think that as these slides are in english I don't see real value in using italian right now.

mercoledì dic 03, 2008

Solaris Technical Workshop

Ho preparato queste slide per un workshop tecnico su Solaris, utilizzando in parte i contributi già esistenti su tematiche di interesse come ZFS, DTrace, ecc.

Solaris Technical Workshop
View SlideShare presentation or Upload your own. (tags: workshop features)

martedì ott 14, 2008

Tornare indietro nel tempo con ZFS ed OpenSolaris

Una delle nuove funzionalità della prossima distribuzione OpenSolaris 2008.11 sarà la possibilità di navigare "indietro nel tempo" all'interno delle proprie cartelle e, di conseguenza, di  poter recuperare versioni precedenti o cancellate dei propri file. Ciò è possibile grazie all'integrazione all'interno del desktop Gnome (ed in particolare dell'applicazione Nautilus) di uno "slider" che permette di consultare gli snapshot creati su un file system ZFS.

Infatti la distribuzione OpenSolaris 2008.11 sarà al 100% su ZFS, inclusi swap e dump device, con l'ulteriore vantaggio di non dover partizionare lo spazio tra i file system e l'area di swap.

Ecco un'immagine che credo renda l'idea, ma maggiori informazioni sono disponibili sul blog di Erwann:


OpenSolaris, ZFS e MySQL: un po' di test in produzione

Ecco alcune interessanti prove effettuate in un ambiente di produzione da Don MacAskill (CEO & "Chief Geek" di SmugMug, uno dei migliori servizi di gestione online per le proprie fotografie) con i dati del database MySQL ospitati da un file system ZFS sulla distribuzione OpenSolaris. Lo storage engine utilizzato è InnoDB.

Innovate on OpenSolaris

In particolare sono stati approfonditi dei test sulla componente di compressione trasparente del file system:

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.

mercoledì gen 09, 2008

Una soluzione di Video Editing basata su Thumper, ZFS e iSCSI

Riprendo il blog di Constatin per sottolineare come il sistema Sun Fire X4500 (noto anche come Thumper) possa essere una piattaforma di storage ideale per una soluzione di video editing grazie all'utilizzo di Solaris ZFS come file system ed iSCSI come protocollo di Network Attached Storage (NAS) in grado di integrarsi con soluzioni multi piattaforma basate su applicativi che richiedono un ambiente Windows, Linux o Mac OS X.

L'unica attenzione è quella di disabilitare nelle connessioni TCP l'algoritmo di Nagle che riduce ad un decimo il throughput via iSCSI.

InfoWorld 2008 Technology of the Year Awards: Solaris, ZFS e Thumper

...nel dettaglio: 

ZFS & Mac OS X

ZFS è stato integrato da Apple in modalità read only in Leopard, l'ultimo aggiornamento di Max OS X (corrispondente ala versione 10.5).  Il progetto di porting open source è ora pubblicato sul sito MacOSforge dove sono disponibili gli ultimi sorgenti e binari disponibili, insieme alle FAQ e ai bug noti: 

http://zfs.macosforge.org/

Il link si trova anche partendo dalla pagina ZFS della comunità OpenSolaris nella sezione ZFS  
Porting
:

http://opensolaris.org/os/community/zfs/porting/

martedì ott 30, 2007

ZFS su InfoWorld

Un altro articolo su ZFS, questa volta su InfoWorld. La conclusione è di mantenersi aggiornati su ZFS, perché la sua diffusione nell'IT è destinata a crescere.

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

Installare una zona su UFS e clonarla con ZFS

Il manuale di amministrazione delle zone di Solaris 10 anche nella versione 8/07 (aka Update 4) indica di non installare le zone con zonepath su ZFS, in quanto in tal caso non è ancora supportata la procedura di patching e upgrade.

Per rispettare tale vincolo, ma poter allo stesso tempo sfruttare i vantaggi di ZFS (in particolare snapshot e cloni) è possibile utilizzare come zonepath un filesystem UFS creato su un volume ZFS.

Supponiamo di voler creare una zona "zone1" e poi clonarla in "zone2" e "zone3" senza occupare il triplo dello spazio disco, ma solo lo spazio necessario per le effettive differenze ("delta") delle nuove zone. Questi sono i passi operativi:

  1. Creare un volume ZFS ad esempio da 10GB in un pool di nome "tank"
    # zfs create -V 10g tank/zone1vol
  2. Creare un filesystem UFS nel volume appena creato e montarlo come "/zone/zone1" (il mount può essere reso persistente aggiungendo il filsystem al file "/etc/vfstab")
    # newfs /dev/zvol/dsk/tank/zone1vol
    # mkdir -m 700 -p /zone/zone1
    # mount /dev/zvol/dsk/tank/zone1vol /zone/zone1
  3. Configurare la nuova zona "zone1" in modalità whole root (ovvero con una copia locale di tutti i file di sistema), in modo da evidenziare meglio i vantaggi del cloning (in questo esempio come scheda di rete utilizzo una interfaccia wireless "wpi0")
    # zonecfg -z zone1
    zone1: No such zone configured
    Use 'create' to begin configuring a new zone.
    zonecfg:zone1> create -b
    zonecfg:zone1> set zonepath=/zone/zone1
    zonecfg:zone1> add net
    zonecfg:zone1:net> set physical=wpi0
    zonecfg:zone1:net> set address=192.168.1.201/24
    zonecfg:zone1:net> end
    zonecfg:zone1> info
    zonename: zone1
    zonepath: /zone/zone1
    brand: native
    autoboot: false
    bootargs:
    pool:
    limitpriv:
    scheduling-class:
    ip-type: shared
    net:
            address: 192.168.1.201/24
            physical: wpi0
    zonecfg:zone1> verify
    zonecfg:zone1> commit
    zonecfg:zone1> exit
  4. Installare zone1
    # zoneadm -z zone-one install
    Preparing to install zone <zone1>.
    Creating list of files to copy from the global zone.
    Copying <162382> files to the zone.
    Initializing zone product registry.
    Determining zone package initialization order.
    Preparing to initialize <1220> packages on the zone.
    Initialized <1220> packages on zone.                                
    Zone <zone1> is initialized.
    Installation of <1> packages was skipped.
    The file </zone/zone1/root/var/sadm/system/logs/install_log> contains a log of the zone installation.
  5. Verificare l'installazione della zona
    # zoneadm list -cv
      ID NAME             STATUS     PATH                           BRAND    IP   
       0 global           running    /                              native   shared
       - zone1            installed  /zone/zone1                    native   shared
  6. Verificare lo spazio occupato per questa zona (di tipo whole root), nel mio caso sono circa 2.53GB
    # zfs list
    NAME               USED  AVAIL  REFER  MOUNTPOINT
    tank              11.2G  80.8G    18K  none
    tank/export_home  1.23G  80.8G  1.23G  /export/home
    tank/zone1vol     2.53G  88.3G  2.53G  -
  7. Effettuare il detach della zona
    # zoneadm -z zone1 detach
  8. Per effettuare il flush su disco del filesystem UFS è necessario forzare un lock, in quanto i metadati di UFS sono aggiornati subito su disco, ma i dati sono gestiti dalla cache di sistema (demone fsflush). Se non si forza il lock in scrittura lo snapshot potrebbe contenere dati e metadati tra loro disallineati.
    # lockfs -w /zone/zone1
    # lockfs
    Filesystem           Locktype   Comment
    /zone/zone1          write 
  9. Creare uno snapshot del volume che contiene il filesystem con la zona in detach
    # zfs snapshot tank/zone1vol@detach
  10. Rimuovere il lock, in modo che il file system torni accedibile in scrittura
    # lockfs -u /zone/zone1
  11. Creare due cloni dello snapshot precedentemente creato
    # zfs clone tank/zone1vol@detach tank/zone2vol
    # zfs clone tank/zone1vol@detach tank/zone3vol
    # zfs list
    NAME                    USED  AVAIL  REFER  MOUNTPOINT
    tank                   11.2G  80.8G    18K  none
    tank/export_home       1.23G  80.8G  1.23G  /export/home
    tank/zone1vol          2.53G  88.3G  2.53G  -
    tank/zone1vol@detach       0      -  2.53G  -
    tank/zone2vol              0  80.8G  2.53G  -
    tank/zone3vol              0  80.8G  2.53G  -
  12. Creare i nuovi path e effettuare il mount dei filesystem UFS contenuti nei volumi ZFS clonati (il mount può essere reso persistente aggiungendo il filsystem al file "/etc/vfstab")
    # mkdir -m 700 -p /zone/zone2
    # mkdir -m 700 -p /zone/zone3
    # mount /dev/zvol/dsk/tank/zone2vol /zone/zone2
    # mount /dev/zvol/dsk/tank/zone3vol /zone/zone3
  13. Configurare una nuova zona "zone2" a partire dal filesystem UFS contenuto nel secondo volume e ricordarsi di cambiare l'IP address
    # zonecfg -z zone2
    zone2: No such zone configured
    Use 'create' to begin configuring a new zone.
    zonecfg:zone2> create -a /zone/zone2
    zonecfg:zone2> select net physical=wpi0
    zonecfg:zone2:net> set address=192.168.1.202/24
    zonecfg:zone2:net> end
    zonecfg:zone2> info
    zonename: zone2
    zonepath: /zone/zone2
    brand: native
    autoboot: false
    bootargs:
    pool:
    limitpriv:
    scheduling-class:
    ip-type: shared
    net:
            address: 192.168.1.202/24
            physical: wpi0
    zonecfg:zone2> verify
    zonecfg:zone2> commit
    zonecfg:zone2> exit
  14. Allo stesso modo configurare una nuova zona "zone3" a partire dal filesystem UFS contenuto nel terzo volume e ricordarsi di cambiare l'IP address
    # zonecfg -z zone3
    zone3: No such zone configured
    Use 'create' to begin configuring a new zone.
    zonecfg:zone3> create -a /zone/zone3
    zonecfg:zone3> select net physical=wpi0
    zonecfg:zone3:net> set address=192.168.1.203/24
    zonecfg:zone3:net> end
    zonecfg:zone3> info
    zonename: zone3
    zonepath: /zone/zone3
    brand: native
    autoboot: false
    bootargs:
    pool:
    limitpriv:
    scheduling-class:
    ip-type: shared
    net:
            address: 192.168.1.203/24
            physical: wpi0
    zonecfg:zone3> verify
    zonecfg:zone3> commit
    zonecfg:zone3> exit
  15. La situazione delle zone è la seguente
    # zoneadm list -cv
      ID NAME             STATUS     PATH                           BRAND    IP   
       0 global           running    /                              native   shared
       - zone1            configured /zone/zone1                    native   shared
       - zone2            configured /zone/zone2                    native   shared
       - zone3            configured /zone/zone3                    native   shared
  16. Effettuare l'attach delle tre zone
    # zoneadm -z zone1 attach
    # zoneadm -z zone2 attach
    # zoneadm -z zone3 attach
  17. Lo stato delle zone ora è cambiato
    # zoneadm list -cv
      ID NAME             STATUS     PATH                           BRAND    IP   
       0 global           running    /                              native   shared
       - zone1            installed  /zone/zone1                    native   shared
       - zone2            installed  /zone/zone2                    native   shared
       - zone3            installed  /zone/zone3                    native   shared
  18. Rispetto all'occupazione su disco, le due nuove zone whole root occupano circa 150KB l'una, ma tale valore non è realistico in quanto molte configurazioni di una zona sono effettuate al primo boot
    # zfs list
    NAME                   USED  AVAIL  REFER  MOUNTPOINT
    tank                  11.2G  80.8G    18K  none
    tank/export_home      1.23G  80.8G  1.23G  /export/home
    tank/zone1vol         2.53G  88.3G  2.53G  -
    tank/zone1vol@detach   148K      -  2.53G  -
    tank/zone2vol          150K  80.8G  2.53G  -
    tank/zone3vol          150K  80.8G  2.53G  -
  19. Effettuare il boot delle tre zone su tre terminali diversi, ad esempio per la prima zona si avrebbe (nota: si esce dalla console premendo in rapida successione i caratteri '~' (tilde) e '.' (punto), il carattere '~' su una tastiera italiana si può ottenere con AltGrf + '\^')
    # zoneadm -z zone1 boot; zlogin -C zone1
    [Connected to zone 'zone1' console]

    SunOS Release 5.11 Version snv_72 32-bit
    Copyright 1983-2007 Sun Microsystems, Inc.  All rights reserved.
    Use is subject to license terms.
    Hostname: zone1

    zone1 console login: root
    Password:
    Sep 20 22:37:58 zone1 login: ROOT LOGIN /dev/console
    Sun Microsystems Inc. SunOS 5.11 snv_72 October 2007
    #
  20. Dopo aver atteso un po' di tempo, in modo da lasciar terminare i processi di configurazione per il primo boot, fermiamo le tre zone ed usciamo dalle console (attenzione: questi comandi vanno eseguiti nelle rispettive console delle zone)
    # init 5
    ~.
  21. Vediamo ora l'occupazione "realistica" delle zone clonate
    # zfs list
    NAME                   USED  AVAIL  REFER  MOUNTPOINT
    tank                  11.4G  80.6G    18K  none
    tank/export_home      1.23G  80.6G  1.23G  /export/home
    tank/zone1vol         2.62G  88.0G  2.59G  -
    tank/zone1vol@detach  31.5M      -  2.53G  -
    tank/zone2vol         94.1M  80.6G  2.59G  -
    tank/zone3vol         93.0M  80.6G  2.59G  -

Le zone "clonate" occupano poco meno di 100MB di spazio disco ciascuna.

Questo esempio non analizza le performance  di una configurazione di questo tipo che ha dei pro e dei contro nell'utilizzo di volumi ZFS clonati.

Tutte le considerazioni precedenti rimangono valide se i volumi ZFS utilizzati sono esportati come iSCSI target da un nodo che ha accesso allo storage (il pool "tank" nell'esempio) ad un altro nodo con le zone "installate". In tal caso l'attach ed il detach possono avvenire anche su sistemi differenti (con lo stesso livello di package/patch) e quindi si possono clonare zone da un nodo verso altri.

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