La scena dell'azione della realta' e' [...] un mondo a quattro dimensioni
in cui spazio e tempo sono indissolubilmente legati.
Per quanto profondo sia il baratro che separa nella nostra esperienza la
natura intuitiva dello spazio da quello del tempo, nulla di questa differenza
qualitativa rientra nel mondo obiettivo che la fisica si sforza di definire
al di fuori dell'esperienza diretta. E' un continuo a quattro dimensioni, che
non e' ne' tempo ne' spazio.
Herman Weyl,
stretto collaboratore di Einstein
sabato 31 marzo 2012
L'intuizione e lo spazio-tempo
giovedì 29 marzo 2012
Macche' tecnico
Non credo che ancora qualcuno abbia dubbi sulla natura politica del governo tecnico, ma nel caso leggetevi questo post: Per chi suona la campana
venerdì 23 marzo 2012
Perlsecret
Ogni tanto incontro della documentazione che mi ricorda quale sia il linguaggio piu' bello del mondo.
Ecco il link a perlsecret
Ecco il link a perlsecret
Ragionamenti sulla riforma del mercato del lavoro
Link a due post interessanti dello stesso autore:
Personalmente ritengo che ci sia molto rumore, ma le conseguenze saranno scarse.
Da quanto leggo l'incremento del costo del lavoro a tempo determinato sara' dell'1.4%... mi viene da sorridere. :-)
Cio' mi suggerisce il parallelo dell'applicazione dell'IMU alla Chiesa (Chiesa in senso lato ovviamente).
Sinteticamente, direzione buona, intensita' quasi nulla.
Ovviamente il percorso parlamentare potrebbe ancora annullare gli effetti, seppur minimi.
Qui e' tutto, da un apprendista di terza nomina, in cui ogni apprendistato e' stato ripetuto alla stessa scrivania, ed ora sono quasi 8 anni :-(
Personalmente ritengo che ci sia molto rumore, ma le conseguenze saranno scarse.
Da quanto leggo l'incremento del costo del lavoro a tempo determinato sara' dell'1.4%... mi viene da sorridere. :-)
Cio' mi suggerisce il parallelo dell'applicazione dell'IMU alla Chiesa (Chiesa in senso lato ovviamente).
Sinteticamente, direzione buona, intensita' quasi nulla.
Ovviamente il percorso parlamentare potrebbe ancora annullare gli effetti, seppur minimi.
Qui e' tutto, da un apprendista di terza nomina, in cui ogni apprendistato e' stato ripetuto alla stessa scrivania, ed ora sono quasi 8 anni :-(
sabato 17 marzo 2012
Effetti astrali
Se esistessero le influenze che i nostri antenati pensano dei
corpi celesti sulla nostra vita ne avremmo scoperto gli effetti
visto che riusciamo a misurare effetti di gran lunga piu' deboli.
Antonino Zichici,
Il vero e il falso, pag. 31
mercoledì 14 marzo 2012
Phishing
lunedì 12 marzo 2012
Come i brevetti ostacolano l'innovazione
Interessante articolo: How patents hinder innovation.
giovedì 8 marzo 2012
Finanziamento dei partiti
Interessante articolo sul finanziamento dei partiti: ecco qui.
mercoledì 7 marzo 2012
( san + mdadm + lvm ) <- rsync
Di seguito riporto una breve giornata di lavoro (ieri) in cui, interrotto continuamente dall'attivita' ordinaria, sono riuscito nel mio intento, quello di configurare lo storage di una macchina di backup e documentarlo in questo post.
La configurazione proposta e' corredata da un po' di comandi per ottenere un backup on line con snapshot giornalieri per una validita' settimanale.
La situazione di partenza prevede una lama di un Blade installata con GNU/Linux (distribuzione Ubuntu server 10.04, quindi LTS) collegata alla SAN via fiber channel con doppio path, SAN configurata con un chunk da 5.37 TB.
Non avrei necessita' di utilizzare l'utility mdadm poiche' il raid voluto l'ho definito direttamente dal gestore della SAN (ax4-5 gestito con il software Navisphere), in particolare ho impostato un raid 5 per i 5.37 TB, ma sono presenti due path per raggiungere lo storage.
Cio' equivale a vedere due dispositivi (sda e sdc) lato sistema, ma essi costituiscono semplicemente due percorsi diversi di uno stesso chunk di storage.
Il metodo primitivo e' eseguire un mount utilizzando uno dei due percorsi. Ma perche' decidere di utilizzarne uno in particolare? E' possibile utilizzarli entrambi e demandare al sistema di scegliere tramite politica ad-hoc quale di volta in volta utilizzare? O utilizzarne uno se l'altro cade? Nel caso manuale, se quello a cadere fosse quello utilizzato nel mount, avrei un fault con brutte conseguenze, nel caso di scelta del sistema il problema non sussiste poiche' sceglierebbe il percorso sano. :-) Chiaramente seguiamo la via elegante.
Ok, allora utilizziamo la tecnologia matura del multipath. Ci sono diversi modalita', io preferisco utilizzare l'utility mdadm con il seguente comando
Un rapidissimo giro e vedo dmsetup, in qualche modo l'antagonista di mdadm. Ok, ho un riscontro positivo e successivamente libero la risorsa con i seguenti comandi:
In particolare, da questo thread
Nel senso che i metadata utilizzati di default non erano compatibili con la capacita' dello storage. Pero' ci ha fornito l'indizio per andare avanti e documentandosi un attimino sul superblocco (raid metadata)
Ora veniamo alla questione del volume. Come accennavo precedentemente, e' necessario avere uno storage con un backup live e degli snapshot distanziati temporalmente un giorno per un totale di una settimana, quindi sette snapshot. Vediano ai comandi (la spiegazione generica la trovate facilmente googlando):
e poi
in cui last indica l'ultimo snapshot. Guardiamo nuovamente il volume group
Vediamo che mancano 77.000 extent da utilizzare che diviso 7 fa un totale di 11.000 extent per ciascuno snapshot.
Bene. Formattiamo il volume logico last:
Per creare gli snapshot qualcosa del genere
Nelle precedenti righe ho scelto Tue perche e' martedi' (LANG=en /bin/date '+%a'). :-)
Per gli altri giorni e' analogo. Scrippettino per automatizzare tutto (non volete anche questo, vero?) e il gioco e' fatto. Chiaramente se esiste gia' lo snapshot (che e' quindi vecchio di una settimana), lo si cancella con il comando lvremove e lo si ricrea.
Per quanto riguarda l'oggetto del post abbiamo terminato, anzi quasi terminato,
Rimane il trasferimento del materiale. Il server vecchio ed il nuovo sono in lan. Bene. Riconfiguro /etc/rsyncd.conf, lancio il comando rsync sulla nuova e il trasferimento di 1.4 TB e' iniziato. mi lascia il tempo di scrivere questo post e... ci aggiorniamo per la tempistica.
Ok, siamo arrivati a meta', ma da subito ho notato che andiamo molto ma molto lenti. Verifico che il tratto e 1Gb/s (schede di rete a 1 Gb/s, switch a 1 Gb/s), ma andiamo lenti. Pero' mi sono ricordato che avevamo problemi di performance sul vecchio storage. Pazienza. Il collo di bottiglia non si puo' eliminare, ma fortunatamente lo storage sara' impiegato per altre funzioni. L'rsync corrente finira' in tarda serata, domani nuovo rsync, e poi spostero' la macchina in produzione.
La configurazione proposta e' corredata da un po' di comandi per ottenere un backup on line con snapshot giornalieri per una validita' settimanale.
La situazione di partenza prevede una lama di un Blade installata con GNU/Linux (distribuzione Ubuntu server 10.04, quindi LTS) collegata alla SAN via fiber channel con doppio path, SAN configurata con un chunk da 5.37 TB.
Non avrei necessita' di utilizzare l'utility mdadm poiche' il raid voluto l'ho definito direttamente dal gestore della SAN (ax4-5 gestito con il software Navisphere), in particolare ho impostato un raid 5 per i 5.37 TB, ma sono presenti due path per raggiungere lo storage.
Cio' equivale a vedere due dispositivi (sda e sdc) lato sistema, ma essi costituiscono semplicemente due percorsi diversi di uno stesso chunk di storage.
Il metodo primitivo e' eseguire un mount utilizzando uno dei due percorsi. Ma perche' decidere di utilizzarne uno in particolare? E' possibile utilizzarli entrambi e demandare al sistema di scegliere tramite politica ad-hoc quale di volta in volta utilizzare? O utilizzarne uno se l'altro cade? Nel caso manuale, se quello a cadere fosse quello utilizzato nel mount, avrei un fault con brutte conseguenze, nel caso di scelta del sistema il problema non sussiste poiche' sceglierebbe il percorso sano. :-) Chiaramente seguiamo la via elegante.
Ok, allora utilizziamo la tecnologia matura del multipath. Ci sono diversi modalita', io preferisco utilizzare l'utility mdadm con il seguente comando
mdadm --create /dev/md0 --level=multipath --raid-devices=2 /dev/sda /dev/sdcPurtroppo, dal comando sopra ottengo quanto segue:
Risorsa occupata?? Qualcuno mente.> mdadm --create /dev/...[..] open("/dev/mapper/mpath1", O_RDONLY|O_EXCL) = -1 EBUSY (Device or resource busy) [...]>
Un rapidissimo giro e vedo dmsetup, in qualche modo l'antagonista di mdadm. Ok, ho un riscontro positivo e successivamente libero la risorsa con i seguenti comandi:
> dmsetup lse poi nuovamente
> dmsetup remove_all
ma qui ottengomdadm --create /dev/md0 --level=multipath --raid-devices=2 /dev/sda /dev/sdc
La questione non quadra. Vado a consultare direttamente l'archivio della mailing list del software mdadm, discretamente attiva. Leggo un po' di questioni simili, ma tutti risolti in versioni precedenti a quella utilizzata da me (mdadm - v2.6.7.1).> mdadm --create /dev/...[..] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). [..] [..] sd 0:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
In particolare, da questo thread
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg03953.htmlleggo come risposta
scritta da Neil Brown, proprio l'autore del software. Non scendendo nei dettagli, ma pensava male :-)The amount of each component drive this is actually in use is stored - in the default metadata - in a 32bit number as kilobytes. This sets a limit of 4TB. The version-1 metadata format has a 64bit field. If you use mdadm 2.3, it will automatically select version-1 metadata if you choose a size larger than 2TB (I think).
Nel senso che i metadata utilizzati di default non erano compatibili con la capacita' dello storage. Pero' ci ha fornito l'indizio per andare avanti e documentandosi un attimino sul superblocco (raid metadata)
si ottiene lo storage /dev/md0 voluto. Ripeto per chiarezza, /dev/md0 e' equivalente allo storage precedente (sda e sdc) raggiungibile con due path diversi in maniera trasparente per l'utente.mdadm --create /dev/md0 --metadata=1.0 --level=multipath --raid-devices=2 /dev/sda /dev/sdc
Ora veniamo alla questione del volume. Come accennavo precedentemente, e' necessario avere uno storage con un backup live e degli snapshot distanziati temporalmente un giorno per un totale di una settimana, quindi sette snapshot. Vediano ai comandi (la spiegazione generica la trovate facilmente googlando):
> pvcreate /dev/md0
> pvdisplay
PV Name /dev/md0
VG Name storage
PV Size 5,37 TiB / not usable 1,99 MiB
Allocatable yes
PE Size 4,00 MiB
Total PE 1408547
Free PE 77000
Allocated PE 1331547
PV UUID beHZj3-hBTB-ySYQ-O4em-GFia-6aOA-IMIjbM
e poi
> vgcreate storage /dev/md0e qui siamo sullo standard. Ora calcoliamo quando extent mi occorrono per gli snapshot. Ne ho disponibili 1408547 ciascuno da 4,00 MiB. Calcolo che per gli snapshot mi occorreranno un totale di 77000 extent (posseggo le statistiche di utilizzo nel server precedente ;-) ), quindi devo creare un volume logico di 1331547 extent. Procediamo:
> vgdisplay
VG Name storage
System ID
Format lvm2
[..]
> lvcreate -l 1331547 -nlast storage> lvdisplayLV Name /dev/storage/last
VG Name storage
LV UUID Mrk51R-DtwY-8b0K-zcyN-KwXq-NwHW-4ncucf
LV Write Access read/write
LV Status available
# open 0
LV Size 5,08 TiB
Current LE 1331547
[..]
in cui last indica l'ultimo snapshot. Guardiamo nuovamente il volume group
> vgdisplay
VG Name storage
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 5,37 TiB
PE Size 4,00 MiB
Total PE 1408547
Alloc PE / Size 1331547 / 5,08 TiB
Free PE / Size 77000 / 300,78 GiB
VG UUID xU5lG2-kveU-2pNS-Qwvm-6ZSO-8kM8-upxXmB
Vediamo che mancano 77.000 extent da utilizzare che diviso 7 fa un totale di 11.000 extent per ciascuno snapshot.
Bene. Formattiamo il volume logico last:
> mkfs.ext4 -m1 /dev/storage/last[...]> mkdir -p /storage/last> mount /dev/storage/last /storage/last
Per creare gli snapshot qualcosa del genere
> lvcreate --snapshot --permission r -l 11000 --name Tue /dev/storage/laste montarli
> mkdir -p /storage/snapshot/Tue
> mount /dev/storage/Tue /storage/snapshots/Tue
Nelle precedenti righe ho scelto Tue perche e' martedi' (LANG=en /bin/date '+%a'). :-)
Per gli altri giorni e' analogo. Scrippettino per automatizzare tutto (non volete anche questo, vero?) e il gioco e' fatto. Chiaramente se esiste gia' lo snapshot (che e' quindi vecchio di una settimana), lo si cancella con il comando lvremove e lo si ricrea.
Per quanto riguarda l'oggetto del post abbiamo terminato, anzi quasi terminato,
Rimane il trasferimento del materiale. Il server vecchio ed il nuovo sono in lan. Bene. Riconfiguro /etc/rsyncd.conf, lancio il comando rsync sulla nuova e il trasferimento di 1.4 TB e' iniziato. mi lascia il tempo di scrivere questo post e... ci aggiorniamo per la tempistica.
Ok, siamo arrivati a meta', ma da subito ho notato che andiamo molto ma molto lenti. Verifico che il tratto e 1Gb/s (schede di rete a 1 Gb/s, switch a 1 Gb/s), ma andiamo lenti. Pero' mi sono ricordato che avevamo problemi di performance sul vecchio storage. Pazienza. Il collo di bottiglia non si puo' eliminare, ma fortunatamente lo storage sara' impiegato per altre funzioni. L'rsync corrente finira' in tarda serata, domani nuovo rsync, e poi spostero' la macchina in produzione.
martedì 6 marzo 2012
dmraid vs mdadm
Personalmente utilizzo mdadm, di seguito un articoletto sulla tecnologia raid. Qui il link.
Comunque oggi ho definito un bel multipath con questo comando
Comunque oggi ho definito un bel multipath con questo comando
mdadm --create /dev/md0 --metadata=1.0 --level=multipath --raid-devices=2 /dev/sda /dev/sdccon /dev/md0 di 5907.9 GB.
sabato 3 marzo 2012
Sapere di non sapere...
Sapere di non sapere e' brutto,
ma non sapere di non sapere e' peggio.
Se poi aggiungiamo l'essere convinti di sapere
quando in realta' si ignora...
stiamo proprio messi male.
MS
Iscriviti a:
Post (Atom)