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.

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.

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à attivo, 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

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.

Base10/16 e jumpstarting solaris da linux troubles

Jumpstart da rete, da ambiente misto, server Linux che installa un sistema Solaris 10 su SPARC. Sto rifacendo il clusterino di casa. Come sempre rinfresco i passi da eseguire scorrendo la guida che ho scritto qualche anno fa. Sta qui .

Tutto bene. Finchè non c'è da linkare inetboot con ln -s nominandolo coll'esadecimale del IP della macchina bersaglio.

Qui mi impanico come al solito ... non riesco mai a ricordare come si fà.
Ma alla fine ci arrivo.
Ecco:

Prendi IP, convertilo in forma binaria e da lì a esadecimale!! Ora so dove cercare quando dovrò rifarlo e mi sarò dimenticato; se non entra non entra disse Siffredi in qualche suo film (almeno presumo, mi pare una battuta abbastanza scontata).

Stavolta ho dovuto anche improvvisare passando a obp il kernel da caricare; pareva non essere in grado di trovarlo. Quindi /platform/sun4v/kernel/unix
Probabilmente un effetto collaterale di nfsv4? Indagherò.

Indagato:
apt-get install nfs-user-server

rimuove l'implementazione kernel-nfs e installa quella userspace. Ci avevo preso, era un problema legato a incompatibilità tra nfs4 Solaris e Linux a quanto pare. Basta riavviare il processo dall'inizio e questo va avanti trovandosi il kernel da caricare.

Altra cosa. Se si usa il Network Manager su Linux, è bene disattivarlo o configurarlo perchè l'interfaccia che serve i dati abbia indirizzamento statico per evitare scherzi tipo che tiri giù l'interfaccia.

Altro simpatico problema:

svc.configd: smf(5) database integrity check of:

/etc/svc/repository.db

failed. The database might be damaged or a media error might have
prevented it from being verified.  Additional information useful to
your service provider is in:

/etc/svc/volatile/db_errors

The system will not be able to boot until you have restored a working
database.  svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes.  The command:

/lib/svc/bin/restore_repository

Bla,Bla Bla ... il problema riguarda le opzioni di esportazione dei filesystems in /etc/exports.
La soluzione è esportare così:

/sol/Boot *(insecure,sync,ro,no_root_squash)
/vcdrom *(insecure,sync,ro,no_root_squash)

Ora dovrebbe andare.

Una descrizione di molti altri fastidiosi problemi incontrati in questo tipo d'installazione e relativa soluzione si trova qui

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