Solaris 11 Express OUT!! Upgrade da snv_145

alex@sunbox:~$ ssh oper@depot
Password:
Last login: Thu Nov 18 11:14:52 2010 from sunbox.sanluigi
Oracle Corporation SunOS 5.11 snv_151a November 2010
oper@filebox:~$ head -1 /etc/release
Oracle Solaris 11 Express snv_151a X86

E' uscito, con una marea di aspettative, installato ora! E' una snv_151 upgradabile dal "vecchio" Opensolaris b134/b134b.
In realta' si puo' passare a questa release ufficiale anche da versioni successive. Personalmente ho upgradato da una 145. E' sufficiente forzare l'image-update.

pkg image-update -v -f --be-name sx11_151 --accept

La v e' verbose, f forza l'upgrade anche se l'incorporation non matcha, be-name gli da un nome decente e accept e' una novita': serve ad accettare la licenza d'uso, senza il comando stampa a schermo la licenza ed esce.

Occhio a eventuale upgrade da openindiana oi_147:
ho letto di problemi con il versioning dello zpool; in pratica sx11 non lo riconosce e chiede "giustamente" di fare un bel blowup

Ho appena aggiornato il fileserver cifs, che arriva da una Opensolaris 2009.6 upgrade dopo upgrade ... icap, vscan, cifs e i due zpool raid1 sembrano funzionare, vediamo se reggono allo stress della giornata.

Ora stiamo a vedere che combina Oracle col piu' bel sistema operativo a disposizione ...

Stampatelo in mente!! Mirroring zpool/rpool

zpool attach [-f] pool device new_device

Attaches new_device to an existing zpool device. The
existing device cannot be part of a raidz configuration.
If device is not currently part of a mirrored configura-
tion, device automatically transforms into a two-way
mirror of device and new_device. If device is part of a
two-way mirror, attaching new_device creates a three-way
mirror, and so on. In either case, new_device begins to
resilver immediately.

ZFS Vs, Data Rot

Quite simply, data rot is the result of tiny changes in the magnetic particles that make up the media in hard disks. The effect this has on your data is random but predictable: data loss.

Ho scoperto questo interessante articolo su BigAdmin, che, oltre ad avermi illuminato su questa interessante anomalia dei dischi fissi, parla di come il più rivoluzionario filesystem degli ultimi anni, ZFS, (che non è mio "amico", ma che un giorno lo diventerà) a detta dell'autore, risponde a questo inconveniente.

Si può leggere qui

Apache su Veritas Cluster Server

Mettere Apache in Failover su ZFS sotto Veritas Cluster Server. Ecco come fare.

Il setup ideale riguarda un Service Group presente su due nodi e composto di tre risorse:

• IP
• Apache
• Zpool

Il pool ZFS "zdata" sarà composto di due dischi in mirror (c1t13d0s2 e c1t14d0s2) e un filesystem zdata/www monterà in /data/www.

# zpool create -f zdata c1t13d0s3
# zpool attach -f zdata c1t13d0s2 c1t14d0s2

# zfs create /zdata/www
# zfs set mountpoint=/data/www zdata/www
# zfs set quota=500M zdata/www

Montare il dataset e compilare apache scaricato preventivamente da httpd.apache.org, qualcosa tipo:

# ./configure -prefix=/data/www
# make
# make install

Una ritoccata al file httpd.conf e siamo a posto.
Ora abbiamo ciò che va messo in HA e affidato a VCS. Per questo creeremo il Service Group "apache" e le risorse "apache_ip", "apache_www" e "apache_zpool".

# haconf -makerw

Il container "apache":

# hagrp -add apache
# hagrp -modify apache SystemList sunbox1 0 sunbox2 1
# hagrp -modify apache AutoStartList sunbox1 sunbox2
# hagrp -modify apache Parallel 0

La risorsa "apache_ip" di tipo IP:

# hares -add apache_ip IP apache
# hares -modify apache_ip Critical 1
# hares -modify apache_ip ArpDelay 1
# hares -modify apache_ip IfconfigTwice 0
# hares -modify apache_ip Device hme0
# hares -modify apache_ip Address 192.168.3.20
# hares -modify apache_ip NetMask 255.255.255.0
# hares -modify apache_ip Enabled 1

La risorsa "apache_www", gli attributi qui settati sono d'esempio, sta al sysadmin di turno stabilire come sia meglio definirli a seconda del caso:

# hares -add apache_www Apache apache
# hares -modify apache_www Critical 1
# hares -modify apache_www ResLogLevel INFO
# hares -modify apache_www Port 80
# hares -modify apache_www SecondLevelMonitor 0
# hares -modify apache_www SecondLevelTimeout 30
# hares -modify apache_www EnableSSL 0
# hares -modify apache_www httpdDir /data/www/bin
# hares -modify apache_www EnvFile /data/www/bin/envvars
# hares -modify apache_www PidFile /data/www/logs/httpd.pid
# hares -modify apache_www HostName vcs_www
# hares -modify apache_www User webservd
# hares -modify apache_www ConfigFile /data/www/conf/httpd.conf
# hares -modify apache_www DirectiveAfter -delete -keys
# hares -modify apache_www DirectiveBefore -delete -keys
# hares -modify apache_www Enabled 1

E infine la risorsa "apache_zpool" per il failover del pool zfs:

# hares -add apache_zpool Zpool apache
# hares -modify apache_zpool Critical 1
# hares -modify apache_zpool ChkZFSMounts 1
# hares -modify apache_zpool PoolName zdata
# hares -modify apache_zpool Enabled 1

Per quanto riguarda le dipendenze tra le risorse l'ordine di partenza dovrebbe essere zpool/IP e poi la risorsa apache. VCS sembra gestire lo startup di default nell'ordine in cui le risorse sono inserite nel Service Group. Questo è fonte di guai, perciò esiste la gestione delle dipendenze, il linking ... e va anche usato. Per questo tornerà utile il comando hares -link:

La sintassi chiede di specificare risorsa genitore e risorsa figlio

# hares -link apache_www apache_zpool
# hares -link apache_www apache_ip

In VCS i genitori son molto gentili (o comodi?), e aspettano che i figli si alzino prima di muoversi a loro volta. All'uscita escono per primi, e i figli vanno offline subito dopo. Questo è da tener conto nel setup delle dipendenze.

Il resto fa parte della gestione abituale.

Nuovi StorageTek JX00 e Simple-Thumper

Stavo dando un'occhiata a tre nuovi piccoli storage devices freschi di "forno", appeni usciti dalla fornace di idee di Sun. Cito:

Storage Expansion Arrays

The Sun Storage J4000 Family offers scalable, reliable storage, breakthrough economics, and heterogeneous support across Solaris, Windows, and Linux platforms.

Così sono definiti. In pratica, tradotto, si tratta di tre arrays, e naturalmente per il software RAID viene menzionato Zfs, per quanto riguarda le soluzioni basate su Solaris (e perchè no Mac OS X e FreeBSD, che ne hanno anche loro una implementazione) ... ZFS. Avrebbero potuto aggiungere solo più ...

"basta averne il coraggio!!"

Per fortuna la configurazione comprendente controllers intellgenti sono capaci di RAID hardware nei livelli 0, 1, 10, 1E, 5, 6, 50, 5EE, 60.
Il J4200 e J4400 sono fondamentalmente lo stesso storage, la differenza sta nella capacità e in una dotazione magari più spinta, dove il primo supporta fino a 48 dischi SAS, mentre il maggiore arriva a 192. Parlano di 72Gb/s di capacità di banda quando tutte e sei le porte SAS sono in uso

Ci vanno poco più di 3000 dollari per la configurazione più piccola: 1 J4200 con due dischi.
Come per tutti i nuovi prodotti, la gestione viene affidata alla CAM, che facilita il lavoro di amministrazione ai clienti che non vogliono pagare personale specializzato, e rendono tristi i sysadmin più hard-core che rimpiangono le gioie di interfacciarsi e lavorare sui T3, 3510 e chi più ne ha più ne metta.

Ma ora arriviamo al pezzo che più mi ha visto interessato e più mi ha incuriosito: il J4500!


Eccolo, chi riconoscete da questa foto? E' thumper, il ciccione X4500 con cpu Amd e una bella spatafiata di dischi SATA da 3emezzo!! Anche lui generato per essere una vittima di ZFS, in uno dei primi tentativi di rifilarci il "Filesystem più fico e con più bits del mondo", magari addirittura spalmato su dischi in macchine di produzione :)

E infatti si tratta di Thumper, stesso chassis, ma niente cpu AMD e relativa dotazione, niente Solaris, e al suo posto una non ben precisata controller, 4 porte SAS da 3Gb/s, supporto per dischi SATA da 1 Tera e possibilita di espansione a 4 unità massime per un totale di 192 dischi e altrettanti Terabytes.
Per il raid HW i livelli sono gli stessi supportati dal J4400.
Nella lista dei servers supportati manca l'X4500, mi chiedo perchè.

Comunque è interessante questo prodotto, che sfrutta la peculiarità di storage server dell'X4500, amputato della presenza di Solaris per quei clienti che non necessitano della flessibilità che questo da, e delegando l'amministrazione alla CAM che sicuramente ne semplifica la gestione laddove manca il know-how, in più la possibilità di fondere la capacità di 4 di questi arrays assieme. Un Simple-Thumper?