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}'

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.

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.

Listare i contenuti di un pacchetto

Hp-uX:
swlist | grep $nome_pacchetto
swlist -l file $nome_pacchetto

Solaris:
pkginfo|grep $nome_pacchetto
pkgchk -l $nome_pacchetto|grep Pathname

Debian:
dpkg -l|grep $nome_pacchetto
dpkg -L $nome_pacchetto

Gentoo:
qlist -I $nome_pacchetto
qfiles $nome_pacchetto

Red Hat:
rpm -qa|grep $nome_pacchetto
rpm -ql $nome_pacchetto

Hp-uX: installare multipli depot in un colpo solo

E' frustrante tornare agli anni 90 a volte ... è il feeling che sento quando mi sloggo da una sessione ssh su una 25K con Solaris 10u5 per loggarmi su un Integrity con Hp-uX 11.31 (11i v3). Sapore di terminale "vetusto".
Niente guerre di religione ... tanto che Solaris è better è un dato di fatto :)

Sto avendo a che fare con Hp-uX in questi giorni. Come tutte le cose poco conosciute può essere terribilmente ostico ... quindi un pò di pacchettini da metter su per rendere l'esperienza più piacevole è un must.

uX ha i depot: swinstall è il tool per gestire l'installazione. Dopo aver fatto la guerra son riuscito a installare i pacchetti necessari. Mi son trovato a dover ovviare al problema di non riuscire a installare i pacchetti in un colpo solo; uno alla volta è terribile, ci va un sacco di tempo.

Alla fine, con swcopy e uno scriptino che mi sono prodotto apposta ho automatizzato il processo. E' sufficiente copiare i depot gzippati scaricati dal repository dell'uni dello stato dello Utah e lanciare:

# depota_pota

All'inizio ho create /staff e /staff/depot /staff/archives /staff/old , non serve altro.

#!/bin/sh

PKG_DIR="staff";
OLD="old";
DEPOT="depot";

cd /${PKG_DIR};
if [ `ls /$PKG_DIR|grep *.depot.gz` ]; then
gunzip *
fi

if [ `ls /$PKG_DIR/$DEPOT|grep catalog` ]; then
mv /$PKG_DIR/$DEPOT/* /$PKG_DIR/$OLD/
fi

for i in *.depot
do
swcopy -s ${PWD}/$i \* @ /${PKG_DIR}/${DEPOT}
done
swinstall -s /${PKG_DIR}/${DEPOT}

Dalla GUI si selezionano i pacchetti, si marcano con 'm' e dal menù Actions si seleziona Install ... avanti avanti avanti!!