mercoledì mar 05, 2008

NFSv4.1, pNFS ed iSCSI dalla SNIA Storage Developers Conference

Ecco un po' di informazioni utili provenienti dalla SNIA Storage Developers Conference dello scorso settembre:

Buona lettura!

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.

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.

mercoledì set 12, 2007

E' disponibile Solaris 10 8/07 (Update 4)

E' disponibile per il download Solaris 10 8/07 (noto anche come Update 4).

Tre le novità di questo aggiornamento:

  • supporto per la procedura di Live Upgrade in presenza di non-global zone
  • il Key Management Framework (KMF), che permette una gestione centralizzata di tutte le chiavi di crittografia del sistema
  • il supporto per iSCSI target device, che assieme alle funzionalità già presenti permette di utilizzare sistemi Solaris sia per creare che per accedere ad una SAN basata su IP
  • il supporto per esportare volumi ZFS come target iSCSI
  • una estensione per i file aperti da processi a 32-bit, che possono superare il vecchio limite di massimo 255 file contemporanei aperti (i processi a 64-bit non hanno mai avuto tale limitazione)
  • le zone con brand lx, ovvero i Solaris Containers for Linux Applications, che permettono di consolidare sistemi Linux in container Solaris
  • una nuova sintassi semplificata per la gestione delle risorse con le zone
  • la piena integrazione del resource capping (rcap) con le zone in modo da poter fissare un tetto per l'utilizzo di memoria fisica, swap e memoria locked (non swappable)
  • le IP Instance, ovvero la possibilita' di separare LAN e VLAN delle non-gobal zone in modo cha abbiano un proprio stack TCP/IP ed una propria tabella di routing
  • l'utilizzo di DTrace nelle non-global zone (tramite l'aggiunta di opportuni privilegi alle zone)
  • l'integrazione di PostgreSQL 8.2 con l'ambiente Solaris (standby a caldo, ricostruzione degli indici a caldo, sonde DTrace specifiche per PosgreSQL, ecc.).
  • Firefox 2.0 & Thunderbird 2.0
  • ...e molto altro ancora...

Per maggiori dettagli e' possibile consultare il documento Solaris 10 What's new o la press release ufficiale.

mercoledì apr 04, 2007

Possibili sinergie tra ZFS e iSCSI

ZFS ed iSCSI sono probabilmente le due tecnologie più innovative in ambito storage degli ultimi anni. E' interessante notare come il loro uso combinato possa creare delle sinergie e quindi delle architetture di storage di nuova generazione.

Ad esempio è possibile implementare una architettura di storage scalabile utilizzando come componenti dei Data Server (ovvero sistemi dotati di un considerevole storage interno) come i Sun Fire X4500 (ciascun X4500 è dotato di 48 dischi SATA da 500GB, per un totale di 24TB di spazio raw). Su ciascun Data Server è possibile configurare un unico storage pool in configurazione raidz da circa 20TB utili e su questo creare uno o più volumi ZFS da esportare come target iSCSI. Un server "applicativo" che dovrà utilizzare lo storage potrà montare via iSCSI i volumi di N sistemi X4500, ciascuno configurato come indicato precedentemente, e configurarli in uno storage pool "virtualmente locale" a sua volta eventualmente in raidz per garantire l'affidabilità in caso di guasto di un Data Server. Su tale pool si possono creare i file system ZFS su cui lavorare. Ogni lettura/scrittura su tali file system è automaticamente distribuita su più Data Server (in base alla configurazione dello storage pool del server "applicativo") e, all'interno dei Data Server, su tutti i dischi (in base alla configurazione dello storage pool dei Data Server), con un accesso distribuito estremamente performante e scalabile. La scalabilità è garantita in quanto aggiungendo uno o più  Data Server è possibile configurarli nello storage pool del server "applicativo" ed il nuovo spazio è reso automaticamente visibile da ZFS ai file system allocati nello storage pool, rispettando ovviamente tutte le policy di quota e reservation preventivamente impostate.

[Read More]

lunedì mar 26, 2007

It's the end of the SAN as we know it

(and I feel fine)

Parafrasando i R.E.M. di Eponymous si può introdurre un discorso piuttosto ampio su quale sia l'evoluzione in corso nelle tecnologie per l'accesso ai dati, partendo dalle attualli Storage Area Network (SAN) e considerando l'evoluzione degli standard rilevanti ed i trend di mercato (come la "virtualizzazione") che tendono sempre più ad astrarsi dalle problematiche "fisiche" delle infrastrutture del datacenter.

Oggi esiste una replicazione delle reti interne ad un datacenter: c'è una rete locale per i protocolli basati su IP (la Local Area Network, o LAN) ed una rete dedicata ai dati (la Storage Area Network, o SAN). Le LAN possono implementare reti 10 Gbit/s su trasporti in fibra o rame attraverso lo standard 10 Gigabit Ethernet (10GbE). Le SAN, basate sul protocollo Fibre Channel, possono implementare reti 4 Gbit/s su un trasporto di tipo fibra.

Lo sviluppo degli standard Ethernet è molto più veloce di quello Fibre Channel. Mentre FC sta lavorando per arrivare a 8 GB/s, il comitato di specifica Ethernet sta lavorando adesso per i 100 GB/s. In questo modo la differenza in termini di throughput puro (senza considerare gli overhead di protocollo) passerà dagli attuali 6 Gbit/s (10 - 6) a 92 Gbit/s (100 - 8).

Parlando del protocolli è invece opinione diffusa che iSCSI (ovveso SCSI su IP, solitamente su datalink Ethernet) sia più "pesante" dell'FC. Ma con la potenza computazionale degli attuali processori, e se necessario l'utilizzo di tecnologie di tipo "TCP/IP Offload Engine" (TOE) o il progetto Neptune di Sun, l'impatto prestazionale può essere ridotto a piacere.

Un altro punto di interesse è la sicurezza: su TCP/IP esitono standard e metodologie applicabili immediatamente (ad esempio IPsec), mentre su FC il problema è aperto e può essere gestito solo  gestendo la sicurezza a monte (ad es. con un filesystem criptato).

E' quindi possibile (se non probabile) che nei prossimi (3-5?) anni si assisterà ad una convergenza degli standard verso un unica rete (LAN+SAN) che utilizzerà IP come protocollo unico di trasporto. A quel punto che il trasporto fisico sia fibra o rame sarà solo un problema economico. In questo scenario è possibile immaginare una maggiore diffusione di sistemi di tipo "Data Server" il cui confine con i tradizionali sistemi storage sarà divenuto meno marcato di quello che è percepibile oggi.


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