Globaldevices su LOFI

Ora Sun Cluster permette di utilizzare un device LOFI per il Global Device Namespace.
E' sufficiente creare un file con mkfile (di almeno 100 Mb) e passarlo a lofiadm.
Con scinstall in typical mode viene poi richiesto se si vuole usare un LOFS come globaldevice.

Pressochè inutile ... direte ... si, se non si pensa di dover mettere Sun Cluster su una macchina già con Solaris preinstallato senza spazio su disco per creare una slice da dedicare al Global Device Namespace.

Info qui

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/

Sun cluster 3.2: Non-Storage Topology e Interconnect Singolo

Leggendo la Student Guide di Sun Cluster Administration (ogni tanto mi porto avanti con lo studio per la certificazione), nel capitolo riguardante le topologie possibili scopro la Non-Storage Topology. In pratica, è una configurazione senza shared-storage, possibile solo con Sun Cluster 3.2 . Infatti, da come la sapevo io, uno storage condiviso è mandatorio per formare il cluster e soprattutto per il quorum device. Naturalmente con questa topologia è necessario utilizzare un altro tipo di quorum, ad esempio il nuovo quorum server, che può stare su una terza macchina e servire da voting device per N clusters.

Inoltre, testando oggi la nuova update 2 di Sun Cluster, noto la possibilità di avere un solo cluster interconnect, cosa che prima non era fattibile, nè poteva essere in alcun modo definita.

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.

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.

Reinstallare Sun Cluster su un nodo

Per sistemare problemi di configurazione, ho deciso di disinstallare Sun Cluster da un nodo di un two-nodes cluster.
Disinstallazione con scinstall -r e relativo reboot.

A questo punto per reinstallare (m'è già capitato in passato), è possibile utilizzare l'installer script dell'archivio JavaES.

# sh $CD_ROOT/Solaris_x86/installer

A questo punto, al reboot per riaggiungere il nodo va bene:

# cd $CD_ROOT/Solaris_x86/Product/sun_cluster/Solaris_10/Tools
# ./scinstall -i -C cluster -N nodo4 -A trtype=dlpi,name=e1000g1 -m endpoint=nodo4:e1000g1,endpoint=:e1000g1


Usare la GUI testuale di scinstall o clsetup non serve a nulla.

Inoltre è possibile disinstallare Sun Cluster, o pulire un'installazione sporca usando lo script:

# sh /var/sadm/prod/SUNWentsyssc32u1/uninstall

Sun Cluster Proxy File System

Finalmente, sebbene in un blog, qualcuno in Sun ha deciso di spendere qualche parola e un pò di tempo per spiegarci qualcosa sul PXFS (Proxy File System) di Sun Cluster.

Si può leggere qui.

A q2uando la documentazione ufficiale?

Into the Depths of Solaris Cluster

Ormai è deciso, il voucher per la cert Sun Cluster Adinistrator 3.2 con retake "aggratis" sarà mio entro il 20 giugno. 200 euro, 5 minuti di nostalgia per le partite a flipper sacrificate per pagare l'esame e poi ... si studia!

A parte questo ... Stasera viaggiavo per impervie directory con la mezza idea di cercare di sistemare alcune Did in status Fail su un cluster di produzione, quando mi addentro in /usr/cluster/lib. Effettivamente non l'avevo ancora fatto ... ci sono scripts a bizzeffe laggiù, con interprete la più classica delle shell su Solaris, miss Korn, ma anche qualche script sh:

root@prXXXXX1 # file /usr/cluster/lib/scadmin/ql/*|grep ksh
/usr/cluster/lib/scadmin/ql/data_change: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/ql_cleanup: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/ql_lu_begin: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/ql_mount: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/ql_stopapp: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/ql_upgrade_status: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/ql_util: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/replace_bootcluster: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/restore_bootcluster: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/split_mode_upgrade_begin: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/split_mode_upgrade_common: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/split_mode_upgrade_recovery: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/upgrade_partition: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/upgrade_partition_a: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/upgrade_partition_a_common: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/upgrade_partition_b: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/upgrade_partition_b_common: executable /bin/ksh script
/usr/cluster/lib/scadmin/ql/upgrade_status: executable /bin/ksh script

Mica male ... c'è molta roba seria qui in mezzo, come al solito non documentata.

E sotto /usr/cluster/lib/sc c'è anche di meglio, sebbene questa pare sia già inserita in $PATH, probabilmente dal .profile-EIS o dagli "omini" Sun per iniziativa loro o per volere della onnipotente "CheckList":

root@prXXXXXXX1 # file *|grep sh
clvxvm_impl: executable /bin/ksh script
config_ipv6: executable /bin/ksh script
dofsck: executable /bin/ksh script
ipv6_check_ccr: executable /bin/ksh script
newcleventlog: executable shell script
pmfd_debug: executable /usr/bin/sh script
print-show: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
rgmd_debug: executable /usr/bin/sh script
run_reserve: executable /usr/bin/ksh script
sc_publish_event: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
sc_update_hosts: executable /bin/ksh script
sc_update_ntp: executable /bin/ksh script
sc_zonescheck: executable /bin/ksh script
scquorumconfig: executable shell script
scslmthresh: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
tunhb_check_ccr: executable /bin/ksh script
update_quorum_disks: executable /usr/bin/ksh script
vlan_check_ccr: executable /bin/ksh script

Tutti gli scripts hanno una descrizione nell'header, questa serata è stata molto istruttiva :)

Ah, vediamo se ho indovinato sulla provenienza di ./lib/sc in $PATH:

root@prXXXXX1 # cat /.profile-EIS |grep sc
# This file is set up by the setup-standard script.
PATH=${PATH}:/usr/cluster/bin:/usr/cluster/lib/sc

YES!!

Cambiare l'ID di un controller

Preparo un cluster due nodi, Solaris10, Sun cluster 3.2, un bunch di risorse e il RACche installerà il DBA.
Pasticciando con l'initiator-scsi (si, è uno StorEdge Scsi Jbod abbastanza vetusto a fare da shared disk container), mi ritrovo alla fine con c1 come controller connesso al Jbod sul primo nodo e c2 sul secondo.

Mode Ricerca ON

Trovo una risposta molto sintetica ma di inestimabile valore, ed è nientemeno che D. Dhunam a darla sui forums di Sun:

You might try renaming the links in /dev/cfg to how you want, then deleting the /dev links for the c1 and c2 devices, then doing a reconfiguration reboot.

Mode Ricerca OFF
Presto fatto:
cd /dev/cfg
ls -l
lrwxrwxrwx 1 root root 40 Jul 31 14:14 c2 -> ../../devices/pci@1f,0/pci@1/scsi@4:scsi
lrwxrwxrwx 1 root root 53 Jul 31 14:14 c1 -> ../../devices/pci@1f,0/pci@1/pci@2/SUNW,isptwo@4:scsi

mv c1 c3
mv c2 c1
rm -rf /dev/rdsk/c2*
rm -rf /dev/dsk/c2*
reboot -- -rv

Funziona!
Andiamo avanti con l'installazione

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!!!