Per cambiare la label di un disco è necessario usare il comando format in modalità enhanced.
# format -e
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]:
Quando ci si trova a rifare una macchina con relativo storage connesso potrebbe tornare utile. Ad esempio con Veritas Volume Manager è fondamentale labellizare correttamente il disco per poter utilizzare un formato in particolare durante la sua inizializzazione.
Da ricordare che la EFI label è il default che viene usato per dischi da 1 Terabyte in su.
Da ricordare anche che dischi con label EFI non sono compatibili in Diskgroups vxvm CDS, Cross-Platform Data Sharing, che è il formato che li rende importabili su qualsiasi piattaforma e OS per cui è disponibile VxVM.
Visualizzazione post con etichetta veritas. Mostra tutti i post
Visualizzazione post con etichetta veritas. Mostra tutti i post
venerdì 27 marzo 2009
giovedì 19 marzo 2009
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/
Grazie a http://www.datadisk.co.uk/
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:
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".
La sintassi chiede di specificare risorsa genitore e risorsa figlio
Il resto fa parte della gestione abituale.
Il setup ideale riguarda un Service Group presente su due nodi e composto di tre risorse:
- IP
- Apache
- Zpool
# zpool create -f zdata c1t13d0s3Montare il dataset e compilare apache scaricato preventivamente da httpd.apache.org, qualcosa tipo:
# zpool attach -f zdata c1t13d0s2 c1t14d0s2
# zfs create /zdata/www
# zfs set mountpoint=/data/www zdata/www
# zfs set quota=500M zdata/www
# ./configure -prefix=/data/wwwUna ritoccata al file httpd.conf e siamo a posto.
# make
# make install
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 -makerwIl container "apache":
# hagrp -add apacheLa risorsa "apache_ip" di tipo IP:
# hagrp -modify apache SystemList sunbox1 0 sunbox2 1
# hagrp -modify apache AutoStartList sunbox1 sunbox2
# hagrp -modify apache Parallel 0
# hares -add apache_ip IP apacheLa 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 -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
# hares -add apache_www Apache apacheE infine la risorsa "apache_zpool" per il failover del pool zfs:
# 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
# hares -add apache_zpool Zpool apachePer 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:
# hares -modify apache_zpool Critical 1
# hares -modify apache_zpool ChkZFSMounts 1
# hares -modify apache_zpool PoolName zdata
# hares -modify apache_zpool Enabled 1
La sintassi chiede di specificare risorsa genitore e risorsa figlio
# hares -link apache_www apache_zpoolIn 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.
# hares -link apache_www apache_ip
Il resto fa parte della gestione abituale.
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
Alternativa è installare i pacchetti a mano (parlo di Solaris in questo caso):
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
set-node vuole il nome del nodo in questione
set-cluster vuole l'identificativo numerico del cluster
Sul nuovo nodo è necessario digitare il comando:
Ora che l'interconnessione è presente, bisogna aggiungere al cluster il nodo passandogli la configurazione, dal nodo preesistente:
E poi rendete di nuovo read-only la configurazione:
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 -rshScegliere 1 e poi l'installazione senza configurazione.
Alternativa è installare i pacchetti a mano (parlo di Solaris in questo caso):
# pkgadd -d . VRTSjacsIn questo secondo caso bisogna aggiungere la licenza d'uso che sia essa demo o permanente:
# pkgadd -d . VRTSjacsd
# pkgadd -d . VRTSjacsj
# pkgadd -d . VRTSjacsm
# pkgadd -d . VRTSjacsu
vxlicinst -k XXXX-XXXX-XXXX-XXXX-XXXX-XXXda 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/llthostsSul 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
0 sunbox1
1 sunbox2
set-node vuole il nome del nodo in questione
set-cluster vuole l'identificativo numerico del cluster
root@sunbox1 / # cat /etc/llttabSul 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
set-node sunbox1
set-cluster 1
link hme1 /dev/hme:1 - ether - -
link hme2 /dev/hme:2 - ether -
root@sunbox2 / # cat /etc/llttabQuesto file contiene l'eseguibile gabconfig. Il parametro -n specifica il nuovo numero di nodi che formano il cluster
set-node sunbox2
set-cluster 1
link hme1 /dev/hme:1 - ether - -
link hme2 /dev/hme:2 - ether - -
# cat /etc/gabtab
/sbin/gabconfig -c -n2
Sul nuovo nodo è necessario digitare il comando:
#/sbin/gabconfig -cper rendere effettiva la configurazione. Ora verificatela con:
root@sunbox1 / # gabconfig -aUn output molto simile significa che ci siete!!
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
Ora che l'interconnessione è presente, bisogna aggiungere al cluster il nodo passandogli la configurazione, dal nodo preesistente:
#haconf -makerwSul nuovo nodo digitate:
#hasys -add sunbox2
#hastop -sys sunbox2
#rcp /etc/VRTSvcs/conf/config/main.cf sunbox2:/etc/VRTSvcs/conf/
config/
#hastartper avviarlo
E poi rendete di nuovo read-only la configurazione:
# haconf -dump -makeroQuesto modesto how-to è pubblicato su AreaNetworking e visibile qui
venerdì 22 giugno 2007
DMP, AP, MPXIO e chi più ne ha...
Veritas Volume Manager è licenziato gratuitamente e in automatico sul glorioso Photon ( StorEdge A5200).
Si da il caso io ne abbia uno in produzione connesso tramite due SOCAL ad una antica Enterprise 3500 (robe di due UltraSPARC II 400mhz, per la serie una Ultra10 ce la fa prima e più silenziosamente).
Il mio predecessore ha quindi pensato di gestire i 22 dischi FC inseriti nel Photon tramite questo gestore di volumi, e con DMP, il gestore multipathing per failover e distribuzione del carico di Veritas, parte della Storage Foundation. Tutto su Solaris 9 09/05 ben patchato.
Dopo una lunga serie di problemi e fastidi che questa macchina è riuscita a darci nel tempo, è venuto all'attenzione di qualcuno il fatto che Vxvm era il gestore di volumi sul server, questo in contrasto con le "policy aziendali" che volevano che il compito fosse svolto da SDS.
A me il compito di ovviare all' "inconveniente" (che a mio giudizio così sconveniente non era, ma...). Iniziando col deincapsulare i dischi di boot e via via /var /app e tutto ciò che risiedeva sui 6 dischi interni al server... ho fatto il tutto durante un down programmato.
Mancava lo storage array. Decisi di rinviare e sperare che qualcuno dimenticasse.
Per convenzione, i backups del db (che è ciò che risiedeva nel dg datadg residente sul
Photon) sono compito dei DBA, quindi i filesystem su cui risiedono i datafiles, solitamente montati in /dati , io semplicemente, non li backuppo (e nemmeno gli darei un senso farlo, fosse anche con uno snapshot, vedi fssnap).
Morale della favola, saltano due dischi del raid5 del volume vxvm, e non c'è verso per cui riesca a recuperare il filesystem. Qui urge un filesystem nuovo e pulito e relativo backup dei DBAs! Ma ecco la notizia: per qualche motivo, i backups di questo db non sono mai stati fatti, anzi, si era deciso di non farli... come al solito senza dire nulla al sottoscritto!
Perfetto!
Si fa tutto da capo e da zero; viene pianificato il modo migliore per ricostruire il db. Per fortuna è possibile, costa tempo ma è già un miracolo che sia possibile.
Distruggo i volumi, e come richiesto, colgo l'occasione per rimuovere il Veritas e mettere sotto DiskSuite i dischi sul Photon.
Mi viene richiesto di ridondare ancora di più il filesystem dedicato al db, a costo dello spazio disponibile; opto per fare due Simple raid0 in mirror che SDS dovrebbe trattare come un raid1+0 (in accordo a un documento tecnico trovato tempo fa in rete e che appena ritrovo posterò).
Niente di meglio. Ci aggiungo due spare e via:
d100 -m d101 d102 1
d101 8 1 c2t1d0s0 \
1 c2t2d0s0 \
1 c2t3d0s0 \
1 c2t4d0s0 \
1 c2t7d0s0 \
1 c2t8d0s0 \
1 c2t9d0s0 \
1 c2t10d0s0 -h hsp001
d102 8 1 c2t16d0s0 \
1 c2t17d0s0 \
1 c2t18d0s0 \
1 c2t19d0s0 \
1 c2t20d0s0 \
1 c2t22d0s0 \
1 c2t24d0s0 \
1 c2t25d0s0 -h hsp002
Manca solo la gestione del multipathing.
Ora che ho tolto DMP (che tra l'altro, secondo l'assistenza era il possibile motivo di un'altro problema che mi assillava di tanto in tanto dove il loop mi andava OFFLINE e ONLINE causando un desync che magari c'entra anche qualcosa col disastro sul filesystem che sto rifacendo), opto per mpxio, il driver di Solaris dedicato al multipathing (integrato in Solaris10 , anche detto StorEdge Traffic Manager o simili e disponibile da installare per Solaris 9.
Configuro tutto, ma niente; allora mi rileggo le note; tutto molto plausibile (il non funzionamento). Le SOCAL non sono supportate da questo driver. Devo ripiegare sul vecchio, buggato, triste Alternate Pathing (AP2.3).
eh no! nemmeno lui va, la versione di Solaris in uso (9), e la macchina in questione non ne permettono l'uso... mi rimane... un bel nulla!
Niente da fare.
Alla fine si opta per: nessun multipathing (giustificato dalla possibilità di avere resilienza, in quanto le prestazioni su questa macchina non sono un must), e "speriamo" che tenga, in attesa che arrivino i Blades che ospiteranno i servizi residenti su questa macchina.
La morale di questa storia è: leggi due volte le release notes, non fidarti del tecnico che al telefono ti dice che puoi mettere mpxio, e successivamente AP, perchè tanto nemmeno lui ha letto le Release Notes e sta dando le cose per scontato quasi quanto te.
Si da il caso io ne abbia uno in produzione connesso tramite due SOCAL ad una antica Enterprise 3500 (robe di due UltraSPARC II 400mhz, per la serie una Ultra10 ce la fa prima e più silenziosamente).
Il mio predecessore ha quindi pensato di gestire i 22 dischi FC inseriti nel Photon tramite questo gestore di volumi, e con DMP, il gestore multipathing per failover e distribuzione del carico di Veritas, parte della Storage Foundation. Tutto su Solaris 9 09/05 ben patchato.
Dopo una lunga serie di problemi e fastidi che questa macchina è riuscita a darci nel tempo, è venuto all'attenzione di qualcuno il fatto che Vxvm era il gestore di volumi sul server, questo in contrasto con le "policy aziendali" che volevano che il compito fosse svolto da SDS.
A me il compito di ovviare all' "inconveniente" (che a mio giudizio così sconveniente non era, ma...). Iniziando col deincapsulare i dischi di boot e via via /var /app e tutto ciò che risiedeva sui 6 dischi interni al server... ho fatto il tutto durante un down programmato.
Mancava lo storage array. Decisi di rinviare e sperare che qualcuno dimenticasse.
Per convenzione, i backups del db (che è ciò che risiedeva nel dg datadg residente sul
Photon) sono compito dei DBA, quindi i filesystem su cui risiedono i datafiles, solitamente montati in /dati , io semplicemente, non li backuppo (e nemmeno gli darei un senso farlo, fosse anche con uno snapshot, vedi fssnap).
Morale della favola, saltano due dischi del raid5 del volume vxvm, e non c'è verso per cui riesca a recuperare il filesystem. Qui urge un filesystem nuovo e pulito e relativo backup dei DBAs! Ma ecco la notizia: per qualche motivo, i backups di questo db non sono mai stati fatti, anzi, si era deciso di non farli... come al solito senza dire nulla al sottoscritto!
Perfetto!
Si fa tutto da capo e da zero; viene pianificato il modo migliore per ricostruire il db. Per fortuna è possibile, costa tempo ma è già un miracolo che sia possibile.
Distruggo i volumi, e come richiesto, colgo l'occasione per rimuovere il Veritas e mettere sotto DiskSuite i dischi sul Photon.
Mi viene richiesto di ridondare ancora di più il filesystem dedicato al db, a costo dello spazio disponibile; opto per fare due Simple raid0 in mirror che SDS dovrebbe trattare come un raid1+0 (in accordo a un documento tecnico trovato tempo fa in rete e che appena ritrovo posterò).
Niente di meglio. Ci aggiungo due spare e via:
d100 -m d101 d102 1
d101 8 1 c2t1d0s0 \
1 c2t2d0s0 \
1 c2t3d0s0 \
1 c2t4d0s0 \
1 c2t7d0s0 \
1 c2t8d0s0 \
1 c2t9d0s0 \
1 c2t10d0s0 -h hsp001
d102 8 1 c2t16d0s0 \
1 c2t17d0s0 \
1 c2t18d0s0 \
1 c2t19d0s0 \
1 c2t20d0s0 \
1 c2t22d0s0 \
1 c2t24d0s0 \
1 c2t25d0s0 -h hsp002
Manca solo la gestione del multipathing.
Ora che ho tolto DMP (che tra l'altro, secondo l'assistenza era il possibile motivo di un'altro problema che mi assillava di tanto in tanto dove il loop mi andava OFFLINE e ONLINE causando un desync che magari c'entra anche qualcosa col disastro sul filesystem che sto rifacendo), opto per mpxio, il driver di Solaris dedicato al multipathing (integrato in Solaris10 , anche detto StorEdge Traffic Manager o simili e disponibile da installare per Solaris 9.
Configuro tutto, ma niente; allora mi rileggo le note; tutto molto plausibile (il non funzionamento). Le SOCAL non sono supportate da questo driver. Devo ripiegare sul vecchio, buggato, triste Alternate Pathing (AP2.3).
eh no! nemmeno lui va, la versione di Solaris in uso (9), e la macchina in questione non ne permettono l'uso... mi rimane... un bel nulla!
Niente da fare.
Alla fine si opta per: nessun multipathing (giustificato dalla possibilità di avere resilienza, in quanto le prestazioni su questa macchina non sono un must), e "speriamo" che tenga, in attesa che arrivino i Blades che ospiteranno i servizi residenti su questa macchina.
La morale di questa storia è: leggi due volte le release notes, non fidarti del tecnico che al telefono ti dice che puoi mettere mpxio, e successivamente AP, perchè tanto nemmeno lui ha letto le Release Notes e sta dando le cose per scontato quasi quanto te.
Iscriviti a:
Post (Atom)
Visite
