Mount CIFS share protetto su client Solaris

Montare uno share da server Solaris Express (Opensolaris o derivati) in join a dominio Active Directory.
Lo share è protetto da utente di AD password.
Lo si vuole in /etc/vfstab opzionalmente montabile in automatico al boot.

smbutil view "//DOMAIN;user@filedepot"
Share Type Comment
-------------------------------
c$ disk Default Share
docs disk
IPC$ IPC Remote IPC
sii disk

Attiviamo il client cifs:

svcadm enable smb/client

Registriamo le credenziali in locale tramite smbutil, in modo da non aver una richiesta di password al mount e non dover adottare soluzioni poco pulite come mettere le credenziali in chiaro in qualche script o in vfstab:

smbutil login DOMINIO/user
Password for DOMINIO/user: XXXXXXX

Ora montiamo lo share a mano:
mount -Fsmbfs -onoac,noprompt "//DOMINIO;user@filedepot/sii" /sii

O mettendolo in vfstab:
cat /etc/vfstab|grep sii
//DOMINIO;user@filedepot/sii - /sii smbfs - yes noac,noprompt

Potete avere una descrizione delle options da passare al mount con:

man smbfs
man mount
man mount_smbfs

AD Domain Controller fault CIFS log

Ieri c'è stato un major fault sul dominio qui dal cliente. A causa di uno switch critico (non ridondante) il domain controller è stato irreperibile per parecchio tempo.

Il fileserver Solaris (che è in join al dominio) e idmapd se ne sono accorti e hanno loggato regolarmente.

Ecco quando è andato giù ed è tornato su.

Feb 15 11:18:19 filebox idmapd[293]: [ID 696364 daemon.error] Degraded operation (Global Catalog servers not configured/discoverable). If you are running an SMB server in workgroup mode, or if you're not running an SMB server, then you can ignore this message

Feb 15 14:43:57 filebox idmapd[293]: [ID 643943 daemon.notice] Normal operation restored

Aix syslogd

Ottima questa pagina di SoftPanorama sul syslog daemon di Aix:

AIX syslogd implementation of SYSLOG has built-in log rotation capabilities that are specified with optional fields after the log destination:

facility-level destination rotate size s files n time t compress archive path

For example:

*.emerg;*.alert;*.crit;*.warning /var/adm/messages rotate files 4 time 7d compress

This is probably the most clean solution of the problem in comparison with Linux or Solaris solutions. As you can see in addition to rotation you can also specify compression

Strangely enough AIX does not provide any default syslog.conf at all. But for syslogd activation it needs to exist.

Internet Relay Chat Solaris

Circa un paio d'anni fa, ho registrato su Azzurra, il canale #solaris . Un pò colto da un eccesso di entusiasmo, un pò perchè questo canale su quel network manca, e anche perchè mi interessava creare un canale di discussione in italiano per sistemisti italiani che prediligono i sistemi Sun e Solaris.

Su questo canale si incontrano circa 7-8 persone, quasi tutti lavoratori informatici, che lavorano su Solaris esclusivamente o in buona parte.

Certo, sarebbe bello vedere più gente, perchè so che i sistemisti specializzati su queste tecnologie in Italia sono un discreto numero, tra cui alcuni molto in gamba.
Il canale è dedicato a tutto ciò che ruota intorno a Sun, in primis Solaris, è aperto a discussioni su argomenti d'attualità sul tema in oggetto e anche a richieste di aiuto e consigli per risoluzione di problemi e per implementazioni che magari qualcuno già conosce.
Anche Opensolaris e derivati sono benvenuti, sebbene il canale ha come focus la distribuzione Sun del sistema operativo, che in questo momento è Solaris 10 (e da cui deriva il codice sorgente rilasciato come open), e dei prodotti Sun o meno che vi girano sopra. Per quanto riguarda l'hardware, il discorso è diverso, e sebbene i sistemi marchiati Sun Microsystems con architettura SPARC siano la configurazione "of choice", qualsiasi sistema classificabile server SPARC o x86/x64, supportato o meno, può essere incluso in una discussione.

Il canale #solaris è accessibile cliccando qui se avete un client IRC installato oppure via web qui inserendo un nickname e #solaris come channel.

Cheatsheets

Esattamente qui una serie di cheatsheet per avere a portata di mano i comandi per fare un sacco di cose.

Grazie a http://www.datadisk.co.uk/

Netinstalling Solaris Vs. Linux "Broken" NFSd

La fiera delle stranezze che l'implementazione NFS di linux riesce a metter su ogni volta, è incredibile.
Questa volta, installando da rete Solaris 10 U6 ... al momento di montare via NFS il cdrom, l'installer fallisce, verificando i logs sull'install server Debian, mi trovo un:

Feb 24 23:53:39 debian mountd[8682]: Unauthorized access by NFS client 192.168.5.11.
Feb 24 23:53:39 debian mountd[8682]: Blocked attempt of 192.168.5.11 to mount /extra/media

Mmhh ... comincio a giocare senza troppa convinzione col file /etc/exports ... mmh; l'unica cosa che rimane è invariata è l'asterisco che indica che tutti gli hosts hanno permesso di montare l'export:

/srv/sol/Boot *(sync,ro,no_root_squash,all_squash,insecure)
/srv/media *(sync,ro,no_root_squash,all_squash,insecure)

Allora mi ricordo di aver letto qualcosa durante le passate ricerche alle prese con altri problemi legati a nfsd su linux. E cambio così:

/srv/sol/Boot 192.168.5.0/255.255.255.0(sync,ro,no_root_squash,all_squash,insecure)
/srv/media 192.168.5.0/255.255.255.0(sync,ro,no_root_squash,all_squash,insecure)

Funziona!!
E i log confermano:

Feb 25 00:01:18 debian mountd[8758]: NFS mount of /extra/media attempted from 192.168.5.11
Feb 25 00:01:29 debian mountd[8758]: /extra/media has been mounted by 192.168.5.11

Pazzesco ... segno qui da ricordare anche questa scocciatura

Sono arrivate! Niagara System Boards su Sun Fire High-End

Lavorando su sistemi dal Fire 4800 alla 25K, mi è venuto spesso da chiedermi, quand'è che Sun avrebbe cominciato a produrre sistemi High-End in grado di supportare un numero consistente di cpu Niagara.

Sfogliando il System Handbook per cercare la documentazione del 7210, vedo che a inizio anno son state aggiunte delle Uniboards supportate su tutti i sistemi su cui montano le tradizionali Uniboards UltraSPARC III, IV e IV+.

Sono le Sun Fire USBRDT 5240 Uniboards:

Sun Fire USBRDT 5240 Uniboard with 128 GB Memory (32 x 4GB)
2 CPUs (1.2GHz, 8-core UltraSPARC T2+)
2 Drives, RoHS:Y

In un 6900 dovresti poter avere 12 T2+ per un totale di 96 cores!!
Lustrare gli occhietti qui. E qui gli occhietti in PDF

Cerca il comando in OBP

C'è una cosa che molti non sanno, e che non ricordo nemmeno più dove l'ho appresa qualche anno fa.

OBP, diamo per scontato che sappiamo di cosa stiamo parlando, ha un "modo", chiamiamolo così, per aiutare nella ricerca di un comando Forth, istruzione o di qualsiasi cosa si voglia eseguire.

Mettiamo che vogliamo dire a OBP di fare un probe di tutti i devices scsi che sono connessi al sistema, ma non ricordiamo precisamente il comando: c'è forse probe nel nome che non ricordiamo, e quasi sicuramente anche scsi, ma chissà in che ordine:

# sifting probe

ritorna come risultato tutti i comandi che contengono i caratteri probe nell'ordine immesso. Tra i vari risultati troviamo ciò che ci serve, ovvero probe-scsi-all. Anche un sifting scsi ci avrebbe aiutato certamente.
Insomma, io trovo sifting, un pò il tipo di aiuto nel trovare il comando giusto scavando nella memoria che da un ambiente bash grazie all'autocompletamento col e a una variabile $PATH ben settata.

Maledetto initiator ID aka "Scsi initiator ID is now 6"!!

Rifacendo un cluster con un vecchio JBOD scsi come shared storage, sono incorso in un conflitto di target ID nella catena scsi tra lo storage sharato e i due nodi.

In questo tipo di configurazione, uno dei due nodi va configurato ad hoc, agendo su alcuni parametri in OBP, in modo da evitare appunto conflitti.

Questo passaggio l'ho fatto già diverse volte, non tantissime, visto che per lo più capita di lavorare su devices fiber-channel, ma abbastanza da essere routine.

Si tratta di agire sulla variabile scsi-initiator-id di un nodo, portando il valore dal default (7) a 6, e poi inserire uno script in nvramrc, abilitandone l'uso mettendo a true use-nvramrc?. Questo in spiccioli aggira il conflitto tra gli HBA dei due nodi dandogli ID diversi, e poi al caricamento di Solaris, risetta in modo trasparente l'ID. Fatto.

Booto. Parte. Uno sfacelo. Decine di errori con molto poco senso, che tutto dicono, tranne quello che è ovvio (vabbè, l'ho esagerata, il loro senso lo hanno).

C'è da dire, che avevo già installato Solaris10 via flar sui nodi, e anche Sun Cluster che era in installmode, in attesa che designassi una DID come quorum.

Dopo un pò di riavvii stressanti e di set-defaults di OBP e rifacimento dei settaggi di cui sopra, mi illumino. Booto un solo nodo, lo booto -xvsr e osservo:
manca la dichiarazione "Scsi initiator ID is now 6". Viene bypassato, il trucco non viene implementato.

Disabilito il parsing di nvramrc settando a false "use-nvramrc?".
Ribooto ... nulla.
STOP-A brutale! Spengo lo storage. Do un reset-all. Ribooto.
Lo vedo: "Scsi initiator ID is now 6" !!
Poweroff ... accendo il JBOD ... accendo il nodo ... boot -v
Pare andare. Accendo l'altro nodo ... TUTTO OK!!!
Riabilito use-nvramrc? . Riavvio i nodi, tutto va.

Morale della favola:
le modifiche vanno implementate a storage spento (magari prima di installare Solaris, ma non è mandatorio come ho letto in alcuni documenti sull'argomento).
Dopo le modifiche è bene dare un reset-all. Provare che la configurazione venga usata. Spegnere e riavviare a storage acceso. Avviare l'altro nodo per avere conferma.

SCSI Jbod in Sun Cluster

Si può definire questa guida un "cult" di Sun Cluster:

http://docs.sun.com/app/docs/doc/819-2995?l=en&q=sun+cluster+scsi_initiator_id&a=load

Ogni volta che vado a cercarla temo che possa essere stata rimossa. Descrive tra le altre cose come cablare un jbod scsi fisicamente e come settare OBP per far funzionare correttamente la catena scsi tra due nodi e uno o due vecchi storage scsi.

Hp-ux Fiber Channel Multipathing e StorageTek 6540

Ormai da tempo ho la possibilità di lavorare sul 6540, uno degli storage Midrange commercializzati da Sun. Il 6540 è il gemello del DS4800 di IBM, entrambi disegnati da Engenio, proprietà di LSI.
Ha due controllers con 4 porte 4 Gbit ciascuno. Con sistemi Sun SPARC e x64 il multipathing per lo spread e il failover del traffico viene gestito dallo Storagetek Traffic Manager, anche noto come MPXIO, disponibile in bundle su Solaris10 e scaricabile come pacchetto opzionale per le versioni precedenti.
Questo software è disponibile inoltre per Windows e Hp-Ux, tra gli altri, comunque a pagamento.
Hp-uX 11.31 ha un sistema di gestione del carico del traffico SAN nativo; non essendo disponibile il gestore Sun per questi sistemi abbiamo deciso di "give it a try".

Creare una LUN sul 6540 da mappare a un host Rx Integrity dotato di due HBA FC 4Gbit HP AB378-60101, al secolo QLogic ISP24xx, è procedura che segue parametri standard, se si eccettua che va selezionato "Hp-uX" come opzione Driver di Gestione SAN/Sistema Operativo. Naturalmente, sull'host non verrà presentato un singolo device logico virtuale come con mpxio, ma anzi, ben quattro path logici.

Quindi, se per una LUN lato host, su Solaris abbiamo qualcosa tipo:
c2 -> controller fisico 1
c3 -> controller fisico 2
c4 -> controller virtuale (quello a cui si fa riferimento nell'usare il volume)

Su Hp-uX con multipathing nativo avremo:
c2 -> controller fisico 1 controller A
c4 -> controller fisico 1 controller B
c6 -> controller fisico 2 controller A
c8 -> controller fisico 2 controller B

Comodo, vero?

I parametri di default lato host, in questo caso, non vanno bene. Le luns risultano pressochè inutilizzabili. L'algoritmo di bilanciamento di default è round-robin, ma l'implementazione pare incompatibile con l'array in questione, facendo risultare la user experience orribile; a quanto pare il problema sarebbe un continuo ping pong nell'inizializzazione della comunicazione tra target e initiator, che rende instabile e funzionante a singhiozzo l'I/O.

Tramite scsi_mgr, è possibile impostare parecchi parametri, tra cui anche l'algoritmo di bilanciamento. Una soluzione provata è stata quella di impostare la politica di bilanciamento dell'host come "usa il path più scarico". Questo ha fatto migliorare sensibilmente l'usabilità, ma risulta in una ennesima "incomprensione" tra host e storage, e quest'ultimo genera un warning ogni volta che l'host cambia il path in uso, essendo in disaccordo sul cambio di controller; viene effettivamente forzato e lo vede come un possibile problema.

Il 6540 lavora con la logica del preferred controller. Alla creazione del volume, esso gli assegna un preferred, che sarà la controller che cercherà di usare come primaria. Usando MPXIO, il sistema è in grado di comunicare e "collaborare" con lo storage per permettergli di seguire la sua logica di funzionamento. Il Native MP di Hp-uX 11i v3 non è in grado di seguire e collaborare a questa gestione dinamica, o per lo meno, non si accorda con lo storage per il cambio di path. Questo significa guai.
La soluzione in questo caso è stata forzare questo comportamento con una gestione manuale, individuando lato host il path corrispondente al preferred scelto dal 6540 e settandolo su Hp-uX come tale, stessa cosa per il secondario. Questo pare aver dato una configurazione funzionante, le prestazioni sembrano ok e nessun warning viene più generato.
Dai test eseguiti, ovvero, un reboot e la disconnessione fisica della fibra, sembra essere tutto ok.
Ovviamente, a ogni nuova lun creata si ripropone il problema di mappare correttamente sull'host i path primario e secondario come li sceglie lo storage.

Sarebbe interessante sapere come si sono "aggiustati" altri amministratori e avere qualche informazione in più sulla cosa. Sarebbe anche interessante vedere l'implementazione di mpxio su hp-ux.

UPDATE:In realtà sulla 11.31 esiste , il nuovo standard per la nomenclatura dei mass storage devices, che coesistendo col vecchio schema definito ora "legacy addressing", lo va a rimpiazzare e sarà l'unico metodo in una prossima release.

Sun T5440, piccoli servers crescono

Aumenta il numero di cpu nei sistemi della serie T di Sun. Si tratta di hardware equipaggiato con fino a 4 Cpu Niagara T2 con 8 cores per una frequenza di 1,4Ghz. Questi sistemi supportano fino a mezzo Tera di RAM; dalla T1000 equipaggiata con un Niagara T1 la potenza di questi sistemi con architettura sun4v sta crescendo esponenzialmente: era proprio quello che mancava e ciò che non mi ha permesso di considerare questo hardware appetibile per ambienti Enterprise fin'ora. L'aspetto è identico a quello degli x4500 equipaggiati con cpu AMD.


Mi chiedo se vedremo sistemi High-End con numero di cpu comparabili a quello delle attuali 20-25K, magari con il prossimo nato, Rock, che promette 16 core. Da una mail sulla mailing-list fm-discuss estraggo questi interessanti links, grazie a Scott Davenport:

For general information about the T5440:
http://www.sun.com/servers/coolthreads/t5440/
There's also a growing collection of T5440-realted blogs organized here:
http://blogs.sun.com/allanp/entry/sun_s_4_chip_cmt
http://blogs.sun.com/sdaven/entry/fma_for_t5440 has the FMA specifics.

Aggiungere hosts a uno shared QFS

Ecco gli steps necessari ad aggiungere dei servers agli hosts che sharano un fs qfs denominato "qfs" .
I files da configurare sono 2 + 1 da verificare. La directory contenente la config è /etc/opt/SUNWsamfs

root@box3 # ls /etc/opt/SUNWsamfs/
VERSION.4.6 hosts.qfs notify.cmd
startup mcf scripts

- hosts.qfs , basta editarlo su uno degli hosts e copiarlo sugli altri.

root@box3 #cat hosts.qfs
box1 172.30.10.1 1 - server
box2 172.30.10.2 2 -
box3 172.30.10.3 3 -

Si commenta da se. Il server è la macchina 1, gli altri sono potenziali
metadata servers nell'ordine di diritto dato dal numero nella terza colonna.

- mcf:
root@box3 # cat mcf
qfs 10 ma qfs - shared
/dev/dsk/c4t6d0s0 11 mm qfs -
/dev/dsk/c4t6d0s7 12 mr qfs -

Contiene la struttura di volume e filesystem. Va definito uno stesso
filesystem su tutte le macchine, specificando un identico nome (in
questo caso "qfs") e definendo come sopra data e metadata slices, ma soprattutto mettendo la dicitura shared.
Attenzione a un'errore banale, ma facile che possa capitare di incapparci. Il
logical device path della lun in uso dalle 4 macchine va definito localmente
su ogni host, appunto ha significanza locale, con il path "corretto". Ad esempio su box1 è
/dev/dsk/c3t6d0 mentre sulla 3 /dev/dsk/c4t6d0. Cambia il controller per la stessa lun da sharare, è un errore non accorgersene andando a inserire un device errato nell'mcf.

mcf è il file dove si va ad agire quando si intende ingrandire il filesystem. Qui si aggiungono le luns da assegnare come spazio per dati e metadati.

- /etc/inittab . Contiene la riga:
sf:023456:respawn:/usr/lib/fs/samfs/sam-fsd
Verificare che non sia stata precedentemente commentata (ad esempio in seguito a shutdown del demone qfs conseguente a rimozione del filesystem shared.

Potrebbe essere necessario avviare i demoni:
/etc/init.d/samfs.shared start

Si lancia il comando
root@box3 # samsharefs -u qfs

Che rilegge il file hosts.qfs e aggiorna la configurazione del demone in accordo ad esso.
Se il filesystem è smontato su uno degli hosts, allora usa:
root@box1 # samsharefs -u -R qfs # !!! OKKIO !!! usare l'opzione -R solo se il fs è SMONTATO , se è MONTATO si rischia una corruzione, usare solo -u
root@box1 # samd config
Configuring SAM-FS

partendo dal metadata server e passando poi alle altre macchine.
Quest'ultimo comando applica i cambiamenti. E' possibile montare i filesystems se non lo si è già fatto.

Un paio di comandi di verifica, utili anche nel caso di problemi durante operazioni del genere:
- samsharefs qfs
- samfsinfo qfs

root@box3 # samsharefs qfs
#
# Host file for family set 'qfs'
#
# Version: 4 Generation: 28 Count: 4
# Server = host 2/box3, length = 138
#
box1 172.30.10.1 1 -
box2 172.30.10.2 2 -
box3 172.30.10.3 3 - server

root@box3 # samfsinfo qfs
samfsinfo: filesystem qfs is mounted.
name: qfs version: 2 shared
time: SatAug 1 22:00:00 CET 2008
count: 2
capacity: 000000000047f000 DAU: 64
space: 0000000000370a40
meta capacity: 0000000000080000 meta DAU: 16
meta space: 00000000000706e0
ord eq capacity space device
0 11 0000000000080000 00000000000706e0 /dev/dsk/c4t6d0s0
1 12 000000000047f000 0000000000370a40 /dev/dsk/c4t6d0s7

Rimane da testare il corretto switch del server; il freeze del
filesystem durante lo switch è abbastanza trasparente, discretamente veloce, e comunque tutte le operazioni vengono messe in attesa e portate a termine appena il sistema torna disponibile.
E' possibile forzare lo switch così:
root@box3 # samsharefs -s HOSTNAME qfs

Si vedrà qualcosa di molto simile:
Aug 1 15:36:06 box1 samfs: [ID 145691 kern.notice] NOTICE: SAM-QFS:
qfs: Failing over to new server box3, frozen (2000821)
Aug 1 15:36:06 box1 samfs: [ID 668864 kern.notice] NOTICE: SAM-QFS:
qfs: Set client: new server box3 (2000821), 1.3, fl=0
Aug 1 15:36:06 box1 samfs: [ID 665295 kern.notice] NOTICE: SAM-QFS:
qfs: Reset leases, then send resync message to new server box3,
thawing (4000821)
Aug 1 15:36:10 box1 samfs: [ID 999740 kern.notice] NOTICE: SAM-QFS:
qfs: New server box3 (8800811) responded to resync message, thawing
(4800821)
Aug 1 15:36:10 box1 samfs: [ID 515541 kern.notice] NOTICE: SAM-QFS:
qfs: Waiting for new server box3 (8800811): thawing (4800821)
Aug 1 15:36:12 box1 samfs: [ID 206251 kern.notice] NOTICE: SAM-QFS:
qfs: Received faildone message from new server box3, thawing (4c00821)
Aug 1 15:36:12 box1 samfs: [ID 685965 kern.notice] NOTICE: SAM-QFS:
qfs: Failed over to new server box3: (21)

Dovrebbe essere tutto. Per aggiunte, correzioni, estensioni, commenti:
FALLE in un commento, scrivimi a alex.t@areanetworking.it e diventeranno a disposizione su questo blog

Bind: Aggiungere nuove entry nel file di zona

Un piccolo script che aggiunge nuove entries nei files di zona.
Fa:
- aggiunge, rimuove e fa il reload
- incrementa il seriale in automatico
- chiede conferma se IP o nome sono già presenti

In realtà l'opzione -r ancora non funziona e l'opzione -u è banale. Per ora mi sono concentrato sull'aggiunta dei records, che è praticamente completa.

#!/bin/bash
#
# AddNameToBind 0.99b
# 2008 Alessandro Torchia

ZONE="my.local.zone";
LIST=`cat $ZONE|egrep 'IN|A|MX|CNAME|^pr|^pp'`
IPLIST=`cat $ZONE|egrep 'IN|A|MX|CNAME|^pr|^pp'|awk '{print $4}'|grep -vi "@"`
NAMELIST=`cat $ZONE|egrep 'IN|A|MX|CNAME|^pr|^pp'|awk '{print $1}'|grep -vi "@"`
NAME=$2;
IP=$3;
TYPE=$4;
ADD=0;
function conferma() {

read -n1 -p "onferma, gnora Vuoi inserire comunque il nome? "
echo
case $REPLY in
c | C)
echo "Continuo con l'update del file di zona ..."
ADD=0;
return $ADD
;;
i | I)
echo "Ignoro l'update ..."
ADD=1;
return $ADD
;;
* )
echo "You don't know what you want to do..."
;;
esac
}

while [ "${1:0:1}" = "-" ];do
case "$1" in
'-a')
for i in $IPLIST
do
if [ $i == $IP ]; then
echo "IP ADDRESS già presente";
conferma
else
ADD=0;
fi
done
for h in $NAMELIST
do
if [ $h == $NAME ];then
echo "NOME già presente";
conferma
else
ADD=0;
fi
done

if [ $ADD != 1 ];then
echo "$NAME IN $TYPE $IP" >> $ZONE;
SERIAL=`cat $ZONE|grep Serial|awk '{print $1}'`;
let NEWSERIAL=$SERIAL+1
cp $ZONE /tmp/$SERIAL
cat /tmp/$SERIAL|sed -e 's/'$SERIAL'/'$NEWSERIAL'/' > $ZONE;
fi
;;

'-r')
# echo "Not Implemented";
cat $ZONE | while read line;
do
REM=`echo $line|grep $NAME`
sed s/'$REM'/''/
done

;;

'-u')
# echo "Not Implemented";
rndc reload

;;
esac


shift
shift
done
if [ "x$1" = "x" ]; then
echo "Usage: $0 main_variable";
echo "Options:";
echo " -a ";
echo " -r ";
echo " -u #Updates bind configuration";
exit 1
fi

Aggiornamenti su questo post as soon as li implemento!

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?

IPMP Link-Based

Ho appena configurato IPMP su una macchina particolare:
si tratta di un Solaris 10u4 x86_64 virtualizzata su un BladeCenter a tre lame quad-opteron, tre nodi di un cluster Vmware ESX Infrastructure 3.0.2
Una LUN raid5 di 1 Terabyte è mappata raw direttamente da uno dei moduli di un Totalstorage DS4700; essa ospiterà un'istanza Oracle che farà da archivio referti.

Questa VM è dotata di due NIC attestate su due set di NIC fisiche diverse per ridondanza.
Si tratta di due Gigabit Ethernet Intel emulate (su Solaris 10 x86_64 è virtualizzata al posto di pcn e vmxnet), ed essendo che il loro driver supporta la modalità Link-Based di IPMP, e che odio la sintassi di configurazione e lo spreco di IP a cui è soggetto la configurazione Probe-Based, decido di usarla.

Configurare la gestione Link Based è di una facilità e pulizia allarmante:

root@ubigasmmg1->cat /etc/hostname.e1000g0
ubigasmmg1 group mmg up
root@ubigasmmg1->cat /etc/hostname.e1000g1
group mmg up
root@ubigasmmg1->svcadm restart physical

Fatto, pronto e funzionante.

Proviamolo:

root@ubigasmmg1->ifconfig -a
e1000g0: flags=1000843 mtu 1500 index 2
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843 mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1

Simuliamo un problema sulla iface e1000g0:

root@ubigasmmg1->if_mpadm -d e1000g0

E verifichiamo:

root@ubigasmmg1->ifconfig -a
e1000g0: flags=89000842 mtu 0 index 2
inet 0.0.0.0 netmask 0
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843 mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1
e1000g1:1: flags=1000843 mtu 1500 index 3
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255

i logs:

Nov 30 02:31:22 ubigasmmg1 in.mpathd[607]: [ID 832587 daemon.error] Successfully failed over from NIC e1000g0 to NIC e1000g1

Ripristiniamo:
root@ubigasmmg1->if_mpadm -r e1000g0

ifconfig dice che tutto è tornato alla situazione iniziale con l'unico IP in uso attestato su e1000g0 (questo ovviamente in accordo al fatto che l'opzione FAILBACK è settata a YES in /etc/default/mpathd). Failback eseguito:

Nov 30 02:33:49 ubigasmmg1 in.mpathd[607]: [ID 620804 daemon.error] Successfully failed back to NIC e1000g0
Nov 30 02:34:19 ubigasmmg1 in.mpathd[607]: [ID 975029 daemon.error] No test address configured on interface e1000g0; disabling probe-based failure detection on it

Quest'ultima riga è significativa di una configurazione Link-based.
Ora vediamo come va. Un problema di cui ho letto è ad esempio il fatto che se uno switch non direttamente connesso al server dovesse cadere, IPMP non se ne accorge, essendo le ICMP request disabilitate non essendo utilizzata la modalità Probe-based. Nell'utilizzarlo è necessario tenere conto di ciò. Inoltre non tutte le NIC sono supportate, comprese alcune molto utilizzate.

Nuovo Sun x4450 Intel Quad-Xeon

http://www.sun.com/servers/x64/x4450/specs.xml

Foto Campus Cluster parte1

Ecco le prime foto delle nuove macchine. Queste sono lo StorageTek 6540 e il Fire E6900 che ho nel CED principale. Le gemelle sono a circa 500 metri da qui in linea d'aria.

Queste macchine andranno a formare il nuovo Campus Cluster in topologia a tre Rooms.

E alla fine si è deciso per optare per Oracle 10 RAC per il db.

Resto in attesa che gli elettricisti ci diano i KW che ci servono per mettere in moto!!
Solo l'E6900 ha 6 power supplies suddivisi in due griglie per un totale di 12KiloWatts!!!

Arrivano i rinforzi

Gran giorno , oggi!
I nostri CED non vantano un massiccio numero di macchine SUN.
Considerando che sono anche l'unico sistemista unix in tutta la struttura, e che i sistemi Midrange che abbiamo sono trattati alla stregua di "mostri", l'arrivo di oggi ha qualcosa di speciale per tutti, e particolarmente piacevole per me.
Abbiamo appena finito di scaricare dal bilico due Fire E6900, due StorageTek Midrange 6540 e una Fire v245.
Andranno a creare il nuovo cluster, naturalmente Sun Cluster (o Solaris Cluster, ultimo cambio di nome del settore marketing che non ha di meglio da fare che creare confusione).

Appena ho tempo qualche foto