Tempo fa vengo a conoscenza di una novità riguardante le zone; oltre all'interessante introduzione del brand Linux, arrivano i containers Solaris 8.
Beh, Sun ha ben pubblicizzato la cosa, ed effettivamente più di una volta avevo pensato a quanto sarebbe stato interessante poter implementare un vecchio server Sol8 in una zona su 10. C'è Etude come strumento per passare dalla teoria alla pratica, e permettere la migrazione "indolore" (forse! Leggi: questo è ancora da vedere), di un vecchio server 8 a una zona anche a un profano di Solaris.
Son stato da clienti, non troppo tempo fa, a fare migrazioni di Db servers Oracle da Solaris 8 a 9, che sembrerà anche surreale, ma non lo è, e spesso la motivazione è la paura che l'applicativo di turno non funzioni, o non sia certificato o supportato dal fornitore "ignorante".
Quello che, invece, io ignoravo, era la possibilità di creare containers Solaris 9, cosa che tra l'altro mi ero chiesto se fosse possibile ogni qualvolta mi capitava di pensare o menzionare a Etude e zone Solaris 8.
Bene, si può. Solo su SPARC, questo è quasi ovvio, e del resto non credo sia nemmeno prevista l'implementazione di zone Solaris 8 e 9 x86 su queste "scrondiche releases", sia perchè effettivamente è meglio dimenticare che sono esistite e considerare Solaris x86 come nato con la release 10, sia perchè da un punto di vista puramente commerciale la base utenti credo sia abbastanza contenuta.
E' invece interessante, per l'architettura x86, seguire l'evoluzione dei BrandZ Linux e di xVM aka Xen.
Stiamo Tuned
martedì 27 maggio 2008
domenica 18 maggio 2008
lofs delirium
Un amico mi chiama sottoponendomi un problema che sta avendo.
Riguarda un'immagine iso montata sotto Solaris, che non si comporta come dovrebbe o ... come lui vorrebbe.
Dice di aver creato il lofs con lofiadm e di averlo montato con successo. Al momento di accedere al mountpoint, però, riceve un:
cd /mnt2
-bash: cd: /mnt2: Not a directory
mmh.
Allora si parte con le domande di rito:
Fai un ls -la di /mnt2:
ls -la /mnt2
brw------- 1 root sys 144, 1 mag 18 21:19 /mnt2
Mmmhh, un block device file. Qualcosa non quadra. Sarebbe necessario capire cosa ha fatto durante la procedura di creazione del loFS e del successivo mount.
Niente history... ma dopo qualche smanettamento infruttuoso m'illumino:
Smonto il filesystem e distruggo il device file; notando che /mnt2 non è una directory ma un device file, sono convinto che abbia montato il device specificando a mount non che si tratta di un'immagine iso, ma appunto di un lofs ... che si può assimilare a distrazione o più probabilmente al fatto di conoscere la procedura, essersi distratto e non aver ben capito cosa si stia facendo. Quindi mount l'ha montato come quello che è, ragionando correttamente (almeno lui).
Ora da vuoto, rifaccio tutto:
creo il device con lofiadm, /dev/lofi/1 , poi creo la dir /mnt2, e lo monto:
mount -F hsfs /dev/lofi/1 /mnt2
df -h|grep lofi
/dev/lofi/1 450M 450M 0K 100% /mnt2
cd /mnt2
ls
sparc worm x64
Perfetto. Funziona.
Il problema è riproducibile, dopo aver creato il lofs desiderato, montandolo cosi:
mount -F lofs /dev/lofi/1 /mnt2
e verificando che /mnt2 è un block device file e non il mountpoint sotto il quale si voleva montare la iso.
Distrazione o errato ragionamento.
Morale;
Montando un loFS, bisogna specificare il tipo di FS al quale esso fa riferimento, e non definendolo come loFS, quando si usa l'opzione -F di mount.
Riguarda un'immagine iso montata sotto Solaris, che non si comporta come dovrebbe o ... come lui vorrebbe.
Dice di aver creato il lofs con lofiadm e di averlo montato con successo. Al momento di accedere al mountpoint, però, riceve un:
cd /mnt2
-bash: cd: /mnt2: Not a directory
mmh.
Allora si parte con le domande di rito:
Fai un ls -la di /mnt2:
ls -la /mnt2
brw------- 1 root sys 144, 1 mag 18 21:19 /mnt2
Mmmhh, un block device file. Qualcosa non quadra. Sarebbe necessario capire cosa ha fatto durante la procedura di creazione del loFS e del successivo mount.
Niente history... ma dopo qualche smanettamento infruttuoso m'illumino:
Smonto il filesystem e distruggo il device file; notando che /mnt2 non è una directory ma un device file, sono convinto che abbia montato il device specificando a mount non che si tratta di un'immagine iso, ma appunto di un lofs ... che si può assimilare a distrazione o più probabilmente al fatto di conoscere la procedura, essersi distratto e non aver ben capito cosa si stia facendo. Quindi mount l'ha montato come quello che è, ragionando correttamente (almeno lui).
Ora da vuoto, rifaccio tutto:
creo il device con lofiadm, /dev/lofi/1 , poi creo la dir /mnt2, e lo monto:
mount -F hsfs /dev/lofi/1 /mnt2
df -h|grep lofi
/dev/lofi/1 450M 450M 0K 100% /mnt2
cd /mnt2
ls
sparc worm x64
Perfetto. Funziona.
Il problema è riproducibile, dopo aver creato il lofs desiderato, montandolo cosi:
mount -F lofs /dev/lofi/1 /mnt2
e verificando che /mnt2 è un block device file e non il mountpoint sotto il quale si voleva montare la iso.
Distrazione o errato ragionamento.
Morale;
Montando un loFS, bisogna specificare il tipo di FS al quale esso fa riferimento, e non definendolo come loFS, quando si usa l'opzione -F di mount.
lunedì 25 febbraio 2008
Acrobat e Ubuntu
Promemoria per l'Ubuntu sul Desktop casalingo sharato con la mia compagna!
Ubuntu non ha acrobat reader nelle repositories, nemmeno in quelle meno restrittive.
E allora googlare "medibuntu" e la soluzione per averlo via apt-get e avere a disposizione le updates è a portata di mano ... assieme a tanto altro software non incluso per beghe legali nelle altre repos
Ubuntu non ha acrobat reader nelle repositories, nemmeno in quelle meno restrittive.
E allora googlare "medibuntu" e la soluzione per averlo via apt-get e avere a disposizione le updates è a portata di mano ... assieme a tanto altro software non incluso per beghe legali nelle altre repos
martedì 19 febbraio 2008
Struttura lo script, Debugga lo script
Pare banale saperlo, ma ci sono volte in cui diventa di fondamentale importanza per sistemare uno script usare gli strumenti giusti.
Ad esempio quando lo script ha dimensioni medio-grandi e gli errori non balzano subito all'occhio.
A me capita di scrivere i miei scripts bash ( si, uso bash, nessuno è perfetto, ed è una delle cose che mi porto dietro da Linux e che non ho mai corretto con un po di sana Korn o C shell, vabbè) di getto, dopo aver gettato una base un minimo strutturata, fondamentale perchè lo script abbia senso e magari sia customizzabile/espandibile in futuro, tiro giù il codice di botto senza preoccuparmi di testare riga per riga e facendo un sacco di errori di sintassi. Questo mi permette di concentrarmi sulla forma e struttura, e di renderlo "usabile successivamente, a lavoro finito. Stare attento a sintassi e piccolezze mi distrae e mi fa perdere l'attenzione allo scrivere qualcosa di davvero funzionale.
Poi viene la correzione assieme al test. E gli errori sintattici non si contano, in genere dimentico i ; o le $ davanti alle variabili, do nomi assurdi alle stesse variabili o cicco per l'ennesima volta la struttura dei cicli, in ultimo dimentico i fi alla fine degli if/else, per non parlare di parentesi o apici.
Una cosa molto utile in questi casi è l'uso delle opzioni di bash -xv direttamente al prompt con un:
# bash -xv script.sh
oppure all'interno dello script passandolo alla dichiarazione della shell in prima riga:
#!/usr/bin/bash -xv
Il risultato è a dir poco eclatante.
Ad esempio quando lo script ha dimensioni medio-grandi e gli errori non balzano subito all'occhio.
A me capita di scrivere i miei scripts bash ( si, uso bash, nessuno è perfetto, ed è una delle cose che mi porto dietro da Linux e che non ho mai corretto con un po di sana Korn o C shell, vabbè) di getto, dopo aver gettato una base un minimo strutturata, fondamentale perchè lo script abbia senso e magari sia customizzabile/espandibile in futuro, tiro giù il codice di botto senza preoccuparmi di testare riga per riga e facendo un sacco di errori di sintassi. Questo mi permette di concentrarmi sulla forma e struttura, e di renderlo "usabile successivamente, a lavoro finito. Stare attento a sintassi e piccolezze mi distrae e mi fa perdere l'attenzione allo scrivere qualcosa di davvero funzionale.
Poi viene la correzione assieme al test. E gli errori sintattici non si contano, in genere dimentico i ; o le $ davanti alle variabili, do nomi assurdi alle stesse variabili o cicco per l'ennesima volta la struttura dei cicli, in ultimo dimentico i fi alla fine degli if/else, per non parlare di parentesi o apici.
Una cosa molto utile in questi casi è l'uso delle opzioni di bash -xv direttamente al prompt con un:
# bash -xv script.sh
oppure all'interno dello script passandolo alla dichiarazione della shell in prima riga:
#!/usr/bin/bash -xv
Il risultato è a dir poco eclatante.
Scelte
Cosa fai quando devi scegliere tra due possibilità di tipo lavorativo e sei costretto a comportarti non troppo bene con l'azienda che ha fatto l'offerta più debole in termini economici, e/o di qualità del lavoro, magari aspettando di firmare da una parte e rifiutando la seconda scelta all'ultimo momento?
Eh? Cosa fai?
Non era una domanda ...
E' semplice retorica. Quello che nell'occasione precedente, poco tempo fa, ha fatto l'azienda di turno con te ...
UPDATE 23/02/2008
Sono giorni di cambio questi,dove mi accingo, tra mille peripezie e slittamenti nelle date, a spostarmi da quel di Trento alla volta di Milano ... nientemeno.
Sono abbastanza contento della scelta, e di alternative vagliabili ne ho avute diverse. Di offerte di lavoro in ambito *nix, nello specifico Solaris, ce ne sono sempre, addirittura nella mia "poco informatica" città natale, dove l'influenza Fiat deve aver inceppato i cervelli, cosicchè un sistemista, pagato in teoria per le sue competenze (che non bastano mai e sono in continuo movimento) e la responsabilità di tenere in piedi con un uptime più che accettabile sistemi, che magari sono vitali per l'esistenza dell'azienda stessa, viene "acquistato" allo stesso costo di un operaio fresco di terza media;
se non altro l'operaio ha i suoi bei benefit e un contratto degno di essere così chiamato (detto fra noi un mio caro amico con la terza media fa l'idraulico/tubista e guadagna un sacco di soldi alla faccia mia).
E mi son sentito dire che la centralinista guadagna la metà di me sistemista, quindi dare di più a me sarebbe farle un torto assimilabile a una ingiustizia piuttosto grave... centralinista, sistemista, scienziati e postini, praticamente la stessa cosa, ma allora che passo a fare la vita lontano da casa e le serate a smazzarmi manuali tecnici?
Eh? Cosa fai?
Non era una domanda ...
E' semplice retorica. Quello che nell'occasione precedente, poco tempo fa, ha fatto l'azienda di turno con te ...
UPDATE 23/02/2008
Sono giorni di cambio questi,dove mi accingo, tra mille peripezie e slittamenti nelle date, a spostarmi da quel di Trento alla volta di Milano ... nientemeno.
Sono abbastanza contento della scelta, e di alternative vagliabili ne ho avute diverse. Di offerte di lavoro in ambito *nix, nello specifico Solaris, ce ne sono sempre, addirittura nella mia "poco informatica" città natale, dove l'influenza Fiat deve aver inceppato i cervelli, cosicchè un sistemista, pagato in teoria per le sue competenze (che non bastano mai e sono in continuo movimento) e la responsabilità di tenere in piedi con un uptime più che accettabile sistemi, che magari sono vitali per l'esistenza dell'azienda stessa, viene "acquistato" allo stesso costo di un operaio fresco di terza media;
se non altro l'operaio ha i suoi bei benefit e un contratto degno di essere così chiamato (detto fra noi un mio caro amico con la terza media fa l'idraulico/tubista e guadagna un sacco di soldi alla faccia mia).
E mi son sentito dire che la centralinista guadagna la metà di me sistemista, quindi dare di più a me sarebbe farle un torto assimilabile a una ingiustizia piuttosto grave... centralinista, sistemista, scienziati e postini, praticamente la stessa cosa, ma allora che passo a fare la vita lontano da casa e le serate a smazzarmi manuali tecnici?
lunedì 18 febbraio 2008
Solaris Performance and Tuning
In questi giorni sono alle prese con una Student Guide che mi ha letteralmente stregato. Di conseguenza, delle 700 pagine che la compongono ne ho già divorate una buona metà. Si tratta della "Solaris System Performance Management", codice SA-400 del 1999 rev B, ancora esistente in una probabile ultima revisione per gli studenti del corso omonimo.
Pensavo di finire questo tomo e poi finalmente passare al "ripassone" per certificarmi Sun Cluster 3.2 Administrator, certificazione che bramo da tempo e per la quale nutro un grande interesse dandogli forma di sfida che vinta, sarebbe una soddisfazione personale non da poco ... e chissà che gioia la mia martoriata autostima, schiava di un signore che non è mai contento dei risultati che raggiunge e pensa sempre che avrebbe potuto fare meglio.
La suddetta Guide è piuttosto datata, tipo 1999, ma il suo contenuto è per la maggior parte sempre attuale; inoltre, essendo le mie conoscenze su Solaris, completamente frutto di autoformazione, il materiale come questo è sempre un ottimo metodo per fare ordine nella testa e affinare argomenti che magari si sono appresi solo in parte per esperienza diretta.
Altra cosa interessante è andare a cercare riferimenti a comandi, settings, opzioni, files di configurazione e tecnologie incorporate e attualizzarle alla release 10 di Solaris che non esisteva al tempo.
Ho trovato tra questa guida e il libro Solaris Performance and Tools - DTrace and MDB Techniques for Solaris 10 and OpenSolaris, molte similitudini nelle argomentazioni.
Ah, naturalmente se avete a portata di mano una versione aggiornata della SA-400 Student Guide sarebbe un'ottimo regalo di compleanno per chiunque dei vostri amici ... e perchè no ... per me
Pensavo di finire questo tomo e poi finalmente passare al "ripassone" per certificarmi Sun Cluster 3.2 Administrator, certificazione che bramo da tempo e per la quale nutro un grande interesse dandogli forma di sfida che vinta, sarebbe una soddisfazione personale non da poco ... e chissà che gioia la mia martoriata autostima, schiava di un signore che non è mai contento dei risultati che raggiunge e pensa sempre che avrebbe potuto fare meglio.
La suddetta Guide è piuttosto datata, tipo 1999, ma il suo contenuto è per la maggior parte sempre attuale; inoltre, essendo le mie conoscenze su Solaris, completamente frutto di autoformazione, il materiale come questo è sempre un ottimo metodo per fare ordine nella testa e affinare argomenti che magari si sono appresi solo in parte per esperienza diretta.
Altra cosa interessante è andare a cercare riferimenti a comandi, settings, opzioni, files di configurazione e tecnologie incorporate e attualizzarle alla release 10 di Solaris che non esisteva al tempo.
Ho trovato tra questa guida e il libro Solaris Performance and Tools - DTrace and MDB Techniques for Solaris 10 and OpenSolaris, molte similitudini nelle argomentazioni.
Ah, naturalmente se avete a portata di mano una versione aggiornata della SA-400 Student Guide sarebbe un'ottimo regalo di compleanno per chiunque dei vostri amici ... e perchè no ... per me
lunedì 11 febbraio 2008
VPN e Desktop remoto; lusso!!
Con la capacità di banda delle connessioni, al giorno d'oggi ci si può "scialare" e offrirsi qualche lusso quando necessario.
Tipo una sessione X remota dalla macchina linux di casa alla workstation Solaris in ufficio?
VPN, rdesktop e magari tsclient sono ciò di cui si ha bisogno.
Per la vpn uso quasi esclusivamente vpnc che funziona egregiamente su qualsiasi sistema operativo; o almeno, io lo uso con successo su diversi flavours di Linux, FreeBSD 8, Solaris 10 e Solaris Express, sebbene questi ultimi due hanno necessitato di qualche ora di scervellamento.
xdmpc e tsclient sono anch'essi disponibili ovunque e laddove non è possibile averli, installare un server vnc è decente alternativa; la cosa carina di tsclient è che offre una gestione centralizzata con possibilità di salvare i profili per le connessioni desktop remoto coi protocolli xdmpc, vnc, rdp, rdp5.
Ultimamente, nei giorni in cui "telelavoro" da casa via vpn Trento-Torino, farcito di Alice 20 Mbit, produco egregiamente, fermandomi solo per pensare quanto il telelavoro in Italia sia un sogno per pochi, e quanti benefici darebbe utilizzarlo.
Tipo una sessione X remota dalla macchina linux di casa alla workstation Solaris in ufficio?
VPN, rdesktop e magari tsclient sono ciò di cui si ha bisogno.
Per la vpn uso quasi esclusivamente vpnc che funziona egregiamente su qualsiasi sistema operativo; o almeno, io lo uso con successo su diversi flavours di Linux, FreeBSD 8, Solaris 10 e Solaris Express, sebbene questi ultimi due hanno necessitato di qualche ora di scervellamento.
xdmpc e tsclient sono anch'essi disponibili ovunque e laddove non è possibile averli, installare un server vnc è decente alternativa; la cosa carina di tsclient è che offre una gestione centralizzata con possibilità di salvare i profili per le connessioni desktop remoto coi protocolli xdmpc, vnc, rdp, rdp5.
Ultimamente, nei giorni in cui "telelavoro" da casa via vpn Trento-Torino, farcito di Alice 20 Mbit, produco egregiamente, fermandomi solo per pensare quanto il telelavoro in Italia sia un sogno per pochi, e quanti benefici darebbe utilizzarlo.
mercoledì 6 febbraio 2008
I tar, You tar , He ...
Da SunManagers (febbraio 2008) Thread Tar question Solaris 9
1. Never archive/backup (tar, cpio) anything by absolute path!
Always 'cd' and use the relative path. Example: you want to
backup /var you should do;
cd /
tar cvf /opt/NOME.tar ./var/* # Notice it is DOT-/var
This will give you an /opt/NOME.tar which you can extract from
anywhere. If you wanted to restore to your REAL /var, you use the
same method as above:
cd /
tar xvf /opt/NOME.tar
Which will extract to 'var' which is relative to / (here).
Of course, you can also:
cd /tmp
tar xvf /opt/NOME.tar
and extract to /tmp/var/...
2. I always prefer to use GNU tar (gtar) to create/extract tarballs.
(On my Solaris9 systems it is: /usr/sfw/bin/gtar)
By default, GNU tar will convert absolute paths to relative paths
(changes leading '/' to './'). gtar is probably not available in
boot -s environment where you have system mounted under /a;
however, IIRC tarballs created with gtar will extract with plain
old tar. You might experiment to verify that it works for you.
Hope this helps.
Hi,
Try this;
cd /var
tar clf - * | (cd /a; tar xpf -)
venerdì 30 novembre 2007
UNpatching di massa
In seguito a un problema sorto dopo un patching di massa di un Solaris10, dove un comando ha cessato di funzionare correttamente, ho deciso di ricorrere alla rimozione delle patch che interessano il binario in questione: si tratta di cfgadm, che semplicemente ha deciso di piantarsi quando lanciato; non muore nemmeno con un kill -9
In /var/sadm/patch ho i riferimenti per il ripristino dei files unpatched.
Vediamo a chi appartiene cfgadm:
pkgchk -l -p `which cfgadm`
mi ritorna un:
Referenced by the following packages:
SUNWcsu
Bene, la mia strategia è di verificare quali patches tra quelle presenti in /var/sadm/patch hanno partecipato alla modifica dell'installato del pacchetto SUNWcsu.
E di conseguenza rimuoverle. Un reboot, la speranza che la macchina "venga su".
Andiamo con ordine. E' necessario uno script, e qui ci si diverte:
Tipo questo:
root@ubigasmmg1->cd /var/sadm/patch
root@ubigasmmg1->for i in `showrev -p|grep SUNWcsu|/usr/xpg4/bin/awk '{print $2}'`
> do
> if [[ `ls -l|awk '{print $9}' |grep $i` ]]; then
> echo $i
> fi
> done
La prima riga apre il for sul risultato di un grep del pacchetto SUNWcsu ripulito con awk. Il particolare di usare quella versione specifica di awk viene dal fatto che il solito /usr/bin/awk aveva dei problemi nel trattare la lista generata da questa catena di pipe, sporcandola.
All'interno del for è necessario inserire la condizione che $i sia presente nella dir attuale; questo perchè, ovviamente, la lista generata nella riga prima è diversa da quella presente in /var/sadm/patch.
Il resto è di semplice comprensione e ne risulta:
125417-04
125500-01
125502-01
125550-01
126146-01
126148-01
126257-04
127112-03
127727-01
127758-01
127877-01
127921-01
127969-01
Ora si può rilanciare lo stesso script con il comando patchrm al posto dell 'echo.
Ha funzionato mica male, ora cfgadm non rimane più appeso senza speranza. Non resta che rileggermi uno a uno i README delle patch rimosse e cercare di capire dove salta fuori l'inghippo
In /var/sadm/patch ho i riferimenti per il ripristino dei files unpatched.
Vediamo a chi appartiene cfgadm:
pkgchk -l -p `which cfgadm`
mi ritorna un:
Referenced by the following packages:
SUNWcsu
Bene, la mia strategia è di verificare quali patches tra quelle presenti in /var/sadm/patch hanno partecipato alla modifica dell'installato del pacchetto SUNWcsu.
E di conseguenza rimuoverle. Un reboot, la speranza che la macchina "venga su".
Andiamo con ordine. E' necessario uno script, e qui ci si diverte:
Tipo questo:
root@ubigasmmg1->cd /var/sadm/patch
root@ubigasmmg1->for i in `showrev -p|grep SUNWcsu|/usr/xpg4/bin/awk '{print $2}'`
> do
> if [[ `ls -l|awk '{print $9}' |grep $i` ]]; then
> echo $i
> fi
> done
La prima riga apre il for sul risultato di un grep del pacchetto SUNWcsu ripulito con awk. Il particolare di usare quella versione specifica di awk viene dal fatto che il solito /usr/bin/awk aveva dei problemi nel trattare la lista generata da questa catena di pipe, sporcandola.
All'interno del for è necessario inserire la condizione che $i sia presente nella dir attuale; questo perchè, ovviamente, la lista generata nella riga prima è diversa da quella presente in /var/sadm/patch.
Il resto è di semplice comprensione e ne risulta:
125417-04
125500-01
125502-01
125550-01
126146-01
126148-01
126257-04
127112-03
127727-01
127758-01
127877-01
127921-01
127969-01
Ora si può rilanciare lo stesso script con il comando patchrm al posto dell 'echo.
Ha funzionato mica male, ora cfgadm non rimane più appeso senza speranza. Non resta che rileggermi uno a uno i README delle patch rimosse e cercare di capire dove salta fuori l'inghippo
IPMP Link-Based
Ho appena configurato IPMP su una macchina particolare:
si tratta di un Solaris 10u4 x86_64 virtualizzata su un BladeCenter a tre lame quad-opteron, tre nodi di un cluster Vmware ESX Infrastructure 3.0.2
Una LUN raid5 di 1 Terabyte è mappata raw direttamente da uno dei moduli di un Totalstorage DS4700; essa ospiterà un'istanza Oracle che farà da archivio referti.
Questa VM è dotata di due NIC attestate su due set di NIC fisiche diverse per ridondanza.
Si tratta di due Gigabit Ethernet Intel emulate (su Solaris 10 x86_64 è virtualizzata al posto di pcn e vmxnet), ed essendo che il loro driver supporta la modalità Link-Based di IPMP, e che odio la sintassi di configurazione e lo spreco di IP a cui è soggetto la configurazione Probe-Based, decido di usarla.
Configurare la gestione Link Based è di una facilità e pulizia allarmante:
root@ubigasmmg1->cat /etc/hostname.e1000g0
ubigasmmg1 group mmg up
root@ubigasmmg1->cat /etc/hostname.e1000g1
group mmg up
root@ubigasmmg1->svcadm restart physical
Fatto, pronto e funzionante.
Proviamolo:
root@ubigasmmg1->ifconfig -a
e1000g0: flags=1000843 mtu 1500 index 2
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843 mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1
Simuliamo un problema sulla iface e1000g0:
root@ubigasmmg1->if_mpadm -d e1000g0
E verifichiamo:
root@ubigasmmg1->ifconfig -a
e1000g0: flags=89000842 mtu 0 index 2
inet 0.0.0.0 netmask 0
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843 mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1
e1000g1:1: flags=1000843 mtu 1500 index 3
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255
i logs:
Nov 30 02:31:22 ubigasmmg1 in.mpathd[607]: [ID 832587 daemon.error] Successfully failed over from NIC e1000g0 to NIC e1000g1
Ripristiniamo:
root@ubigasmmg1->if_mpadm -r e1000g0
ifconfig dice che tutto è tornato alla situazione iniziale con l'unico IP in uso attestato su e1000g0 (questo ovviamente in accordo al fatto che l'opzione FAILBACK è settata a YES in /etc/default/mpathd). Failback eseguito:
Nov 30 02:33:49 ubigasmmg1 in.mpathd[607]: [ID 620804 daemon.error] Successfully failed back to NIC e1000g0
Nov 30 02:34:19 ubigasmmg1 in.mpathd[607]: [ID 975029 daemon.error] No test address configured on interface e1000g0; disabling probe-based failure detection on it
Quest'ultima riga è significativa di una configurazione Link-based.
Ora vediamo come va. Un problema di cui ho letto è ad esempio il fatto che se uno switch non direttamente connesso al server dovesse cadere, IPMP non se ne accorge, essendo le ICMP request disabilitate non essendo utilizzata la modalità Probe-based. Nell'utilizzarlo è necessario tenere conto di ciò. Inoltre non tutte le NIC sono supportate, comprese alcune molto utilizzate.
si tratta di un Solaris 10u4 x86_64 virtualizzata su un BladeCenter a tre lame quad-opteron, tre nodi di un cluster Vmware ESX Infrastructure 3.0.2
Una LUN raid5 di 1 Terabyte è mappata raw direttamente da uno dei moduli di un Totalstorage DS4700; essa ospiterà un'istanza Oracle che farà da archivio referti.
Questa VM è dotata di due NIC attestate su due set di NIC fisiche diverse per ridondanza.
Si tratta di due Gigabit Ethernet Intel emulate (su Solaris 10 x86_64 è virtualizzata al posto di pcn e vmxnet), ed essendo che il loro driver supporta la modalità Link-Based di IPMP, e che odio la sintassi di configurazione e lo spreco di IP a cui è soggetto la configurazione Probe-Based, decido di usarla.
Configurare la gestione Link Based è di una facilità e pulizia allarmante:
root@ubigasmmg1->cat /etc/hostname.e1000g0
ubigasmmg1 group mmg up
root@ubigasmmg1->cat /etc/hostname.e1000g1
group mmg up
root@ubigasmmg1->svcadm restart physical
Fatto, pronto e funzionante.
Proviamolo:
root@ubigasmmg1->ifconfig -a
e1000g0: flags=1000843
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1
Simuliamo un problema sulla iface e1000g0:
root@ubigasmmg1->if_mpadm -d e1000g0
E verifichiamo:
root@ubigasmmg1->ifconfig -a
e1000g0: flags=89000842
inet 0.0.0.0 netmask 0
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1
e1000g1:1: flags=1000843
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255
i logs:
Nov 30 02:31:22 ubigasmmg1 in.mpathd[607]: [ID 832587 daemon.error] Successfully failed over from NIC e1000g0 to NIC e1000g1
Ripristiniamo:
root@ubigasmmg1->if_mpadm -r e1000g0
ifconfig dice che tutto è tornato alla situazione iniziale con l'unico IP in uso attestato su e1000g0 (questo ovviamente in accordo al fatto che l'opzione FAILBACK è settata a YES in /etc/default/mpathd). Failback eseguito:
Nov 30 02:33:49 ubigasmmg1 in.mpathd[607]: [ID 620804 daemon.error] Successfully failed back to NIC e1000g0
Nov 30 02:34:19 ubigasmmg1 in.mpathd[607]: [ID 975029 daemon.error] No test address configured on interface e1000g0; disabling probe-based failure detection on it
Quest'ultima riga è significativa di una configurazione Link-based.
Ora vediamo come va. Un problema di cui ho letto è ad esempio il fatto che se uno switch non direttamente connesso al server dovesse cadere, IPMP non se ne accorge, essendo le ICMP request disabilitate non essendo utilizzata la modalità Probe-based. Nell'utilizzarlo è necessario tenere conto di ciò. Inoltre non tutte le NIC sono supportate, comprese alcune molto utilizzate.
Iscriviti a:
Post (Atom)
Visite
