giovedì 11 dicembre 2008

Informazioni su StorageTek 6540 e Nagios Plugin

Ho trovato questa pagina, che dovrebbe essere un documento operativo sul 6540 di StorageTek; è in norvegese, ma potete incollare il seguente link qui e avere una grossolana traduzione in italico (o altro se si preferisce):
http://hpc.uio.no/index.php/Norstore_operational_document
Ci sono esempi dell'uso della riga di comando e anche una chicca:
il link a un plugin per Nagios per la CAM e la serie 6xxx degli array Sun Storagetek.
Praticamente, questo plugin è uno script perl che va a guardare nella directory dove la CAM mette gli allarmi (solitamente ogni allarme è custodito li sottoforma di file: un allarme - un file); non vedo indicato la directory degli allarmi, ma a memoria sta sotto /var/opt/SUNWsefms in una directory chiamata alarms o notifications (magari find può essere più preciso se gli chiedete).

Nello stesso sito anche altri plugin interessanti per il check di HBA scsi adaptec, Oracle health e MySQL performance, stato di servers HP Proliant ecc ecc

Insomma, una letta questa pagina, la merita.

mercoledì 10 dicembre 2008

Windows: symlinks, hardlinks e shortcuts

Stasera parlavo con la mia compagna dei links su Windows, e mi chiedeva se un Collegamento (shortcut) è un link. A questo proposito mi è venuto in mente un articolo che lessi tempo fa su questo argomento; e me lo sono andato a cercare.

In questo documento viene fatta luce sull'argomento, spiegato il funzionamento dei links su Windows, anche in relazione a Fat e NTFS, presentati alcuni tools per lavorarci, sia in bundle sia di terze parti, e viene anche data risposta alla domanda di sopra:

"No, gli shortcuts non sono links simbolici, sebbene spesso si faccia riferimento ad essi come se lo fossero. D'altra parte, specifica l'autore, gli shortcuts hanno tutti gli attributi per comportarsi come symlinks ed emularne le caratteristiche"

Naturalmente sono benvenuti commenti da più esperti amministratori Windows; possiamo trovare l'articolo "Windows Symbolic and Hard Links" qui

domenica 7 dicembre 2008

Nautilus: piccole curiosità

Navigando il filesystem sul mio portatile conil Nautilus di Gnome, ho dedicato un pò di tempo per imparare qualcosa sui settaggi possibili e migliorare l'usabilità tramite di essi. Questo manager utilizza Gvfs, il Gnome Virtual Filesystem, di recentissima concezione e composto di alcuni demoni e librerie. La visualizzazione degli oggetti può essere a elenco o a icone. La prima restituisce un elenco, uno per riga, di files e directories e i loro attributi; la visualizzazione a icone permette di vedere il contenuto nella classica modalità dove più icone occupano lo spazio su file e colonne identificate dal loro nome a fianco o in basso.

E' possibile decidere quali informazioni sugli oggetti visualizzare dal pannello Preferenze. Tra queste vi è la dimensione. Abilitato i flag dimesione e possibile in modalità elenco, ordinare le dimensione i files. Nel caso di directories, però, non viene visualizzata la dimensione; per loro in questo campo viene conteggiato il numero di oggetti che contiene, siano essi files o dirs.

Ordinando per dimensione i contenuti di una directory mista filess e dirs, verranno visualizzati prima i files e poi le directories, rispettivamente sistemati dal più grande al più piccolo in numero di Megabytes e in numero di oggetti.

Nautilus può essere lanciato con diversi flags, tra i quali, mi è capitato di usare:

--no-desktop per lanciare il file-manager senza il supporto alla gestione della scrivania. Molto utile per utilizzare Nautilus su un altro WM/DE, ad esempio;
--browser server ad aprire una finestra in modalità esplorazione

giovedì 27 novembre 2008

Quanta RAM?

Come vedo quanta RAM c'è dentro quel server?
In un modo "scriptabile"?

Solaris:
prtconf -vp|grep Mem

Hp-uX:
dmesg|grep -i physical
cat /var/adm/syslog/syslog|grep -i physical
/usr/sam/lbin/getmem
print_manifest|grep -i physical

Linux:
cat /proc/meminfo |grep MemTotal:
top -n 1|grep Mem|awk '{print $1,$3}'

giovedì 20 novembre 2008

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.

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.

sabato 8 novembre 2008

Veritas Cluster: aggiungere un nodo e un pò di teoria

Installare Veritas cluster su un secondo o terzo nodo è molto semplice.
E' sufficiente fare un'installazione manuale del software o usare i tools.
E' possibile lanciare l'installer principale di Storage Foundation HA; a me piace usare rsh durante l'installazione (anche di Sun Cluster e il CRS di Oracle), e poi disabilitarlo successivamente.
Cosa da fare presto o tardi è aggiungere /opt/VRTS/bin al $PATH
# ./installer -rsh
Scegliere 1 e poi l'installazione senza configurazione.
Alternativa è installare i pacchetti a mano (parlo di Solaris in questo caso):
# pkgadd -d . VRTSjacs
# pkgadd -d . VRTSjacsd
# pkgadd -d . VRTSjacsj
# pkgadd -d . VRTSjacsm
# pkgadd -d . VRTSjacsu
In questo secondo caso bisogna aggiungere la licenza d'uso che sia essa demo o permanente:
vxlicinst -k XXXX-XXXX-XXXX-XXXX-XXXX-XXX
da verificare con vxlicrep|more.

Una volta terminata l'operazione è possibile passare alla configurazione del nuovo nodo e alla modifica di alcuni files sul/sui nodo/i preesistente/i.

Prima cosa da fare è disporre la comunicazione tra i nodi. di questo compito si occupano LLT e GAB.
Ma cosa sono:
LLT è l'infrastruttura di interconnessione tra i nodi, comprendente le interfacce adibite a questo compito, che è bene siano almeno due per nodo. La gestione delle NIC e dei media di interconnessione avviene in modo trasparente, il traffico viene bilanciato sugli interconnects disponibili; nel caso un'interconnessione venga a mancare vengono usate le altre.
GAB si occupa e si tratta proprio della comunicazione tra i nodi, ovvero dell'heartbeat necessario ai nodi per "sentire" la presenza degli altri. Inoltre tutti gli scambi di informazioni riguardanti cambi di configurazione o failures in qualunque punto del cluster avvengono grazie a GAB. Lui comunica con HAD, il motore del cluster presente sui nodi e intermediario tra i gestori di risorse e LLT/GAB.

I files da editare sono:
/etc/llthosts /etc/llttab /etc/gabtab

Nel nostro cluster, basato su Solaris10 e composto di due nodi aventi una interfaccia pubblica e due di interconnessione tra i nodi dovremo ritrovarci con questi contenuti:

Su entrambi i nodi, qui c'è la lista dei nodi con davanti un numero progressivo
# cat /etc/llthosts
0 sunbox1
1 sunbox2
Sul nodo già a
ttivo, avete questo (a meno che non avete attivato LLT e GAB quando avete installato). Le direttive LLT che vedete di seguito dicono
set-node vuole il nome del nodo in questione
set-cluster vuole l'identificativo numerico del cluster
root@sunbox1 / # cat /etc/llttab
set-node sunbox1
set-cluster 1
link hme1 /dev/hme:1 - ether - -
link hme2 /dev/hme:2 - ether -
Sul secondo e nuovo nodo creerete un file coerente con quanto visto sopra, premurandovi di mettere il nome del nodo su cui siete in set-node. Le ultime due righe identificano le interconnessioni 1 e 2 assegnandogli le NIC
root@sunbox2 / # cat /etc/llttab
set-node sunbox2
set-cluster 1
link hme1 /dev/hme:1 - ether - -
link hme2 /dev/hme:2 - ether - -
Questo file contiene l'eseguibile gabconfig. Il parametro -n specifica il nuovo numero di nodi che formano il cluster
# cat /etc/gabtab
/sbin/gabconfig -c -n2

Sul nuovo nodo è necessario digitare il comando:
#/sbin/gabconfig -c
per rendere effettiva la configurazione. Ora verificatela con:
root@sunbox1 / # gabconfig -a
GAB Port Memberships
===============================================================
Port a gen 2f0a01 membership 01
Port a gen 2f0a01 jeopardy ;1
Port h gen 2f0a04 membership 01
Port h gen 2f0a04 jeopardy ;1
Un output molto simile significa che ci siete!!

Ora che l'interconnessione è presente, bisogna aggiungere al cluster il nodo passandogli la configurazione, dal nodo preesistente:
#haconf -makerw
#hasys -add sunbox2
#hastop -sys sunbox2
#rcp /etc/VRTSvcs/conf/config/main.cf sunbox2:/etc/VRTSvcs/conf/
config/
Sul nuovo nodo digitate:
#hastart
per avviarlo

E poi rendete di nuovo read-only la configurazione:
# haconf -dump -makero
Questo modesto how-to è pubblicato su AreaNetworking e visibile qui

lunedì 27 ottobre 2008

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.

giovedì 16 ottobre 2008

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.

martedì 14 ottobre 2008

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.

Visite