ingtlc.com - Emilio Romano blog


Google
 
Disaster Recovery come procedura aziendale di ripristino negli impianti di telecomuncazioni
domenica 08 novembre 2009
In tema di sicurezza in aziende ed enti pubblici, degli impianti di rete e informatici connessi alle telecomunicazioni, assume ampio rilievo la programmazione di un piano di interventi da attuare su un impianto per prevenire situazioni catastofiche. La gestione dei rischi aziendale costituisce un importante punto nella programmazione delle attività di una azienda (pubblica o privata) e induce, ovviamente dei costi, che variano da azienda ad azienda, relativamente alle proprie priorità. La cattiva se non la completa mancanza di un piano di gestione rischi provoca gravi inefficienze e ritardi nella gestione delle procedure di ripristino; fin quando l'evento non si e' verificato, non esiste di fatto la necessità di avere un piano programmato di disaster recovery. Il problema sorge quando si è davanti l'evento catastrofico alla quale, inevitabilmente, si deve porre rimedio nel breve tempo, per ripristinare il funzionamento dell'impianto e delle attività ad esso coinvolte, (pensiamo ad un centro di calcolo di un istituto di credito il quale deve fronteggiare miliardi di operazioni transazionali sugli apparati TLC. Sarebbe impensabile un malfunzionamento.) ma al quale non sempre si puo' fronteggiare senza aver alle spalle un piano programmato.
Abbiamo parlato di evento catastrofico, di cui intedo non banalmente un evento naturale catastrofico, che pur e' ammesso nella statistica, ma di eventi come:
 
  • Malfunzionamenti hardware 
  • Errori umani
  • Single point of failure
  • Carenza di addetti e competenze specifiche
Impianti general purpouse progettati a regola d'arte, non escludono dalla possibilità che eventi catastrofici possano verificarsi. E' bene quindi applicare delle attività simulative, adeguatamente schedulizzate, per regolare e gestire il piano di disaster recovery da adottare nel caso in cui si verifichino situazioni disastrose. L'impiego di una simulazione non elimina al cento per cento l'eventualità che il piano non fronteggi adeguatamente l'evento e riduca quindi, ritardi e inefficienze, nel ripristino dell'attività dell'impianto.
 
E.Romano 
 
Internet Usage Monitor
sabato 07 novembre 2009

Uptime della mia connessione Alice Telecom e gestione del volume di traffico (router 3COM): Complimenti.

 

 
mount.ntfs-3g causa overloading della CPU
venerd́ 30 ottobre 2009

Nell'articolo precedente e' stato menzionato il problema che il processo mount.ntfs-3g causi un sovraccarico della cpu variabile dal 50% a 100%. Del problema sembra esserne la causa, apparentemente, il software che tenta di leggere/scrivere sulla partizione, tuttavia esso dipende da diversi fattori. In ordine di probabilità sono:

  • Non si sta usando l'ultima versione aggiornata del driver ntfs-3g. In questo caso, scarichiamo e installiamo manualmente l'ultima versione dal sito dello sviluppatore, http://ntfs-3g.org/.
  • Lettura/scrittura di parecchi GBytes di dati su una partizione altamente frammentata. In questo caso, invece, dovremmo procedere alla deframmetazione.
  • La misura del block-size o cluster-size del file system NTFS potrebbe essere troppo piccola. Ad esempio solitamente potrebbe dar problemi una taglia inferiore a 4096. Il che accade a volte quando si trasforma il FS da FAT32 a NTFS.Il driver usa immagazzinare alcune informazioni quali il block size nella cartella /var/logs.Cerchiamo informazione con un grep alla parola "blksize", per esempio.
  • Si sta usando un embedded device o un sistema I/O troppo veloce (>100Mbit/s). Tra parentesi, i vecchi sistemi PIO (Programmable Input Output) caricavano la CPU per l'I/O su HD e sono stati sostituiti dagli UDMA (Accesso diretto alla memoria).
In sostanza se non riusciamo a risolvere il problema, dovremmo anche tenere in considerazione l'eventualità che un carico del 50% sulla cpu da parte del driver, sia relativamente normale. Consideriamo che esistono software in commercio che fanno intenso uso dell'HD come per esempio il sottocitato transmission, ma in generale tutti i client Bit torrent. Potrebbe essere normale anche su altri tipi di file systems, ma non ce ne rendiamo conto, poichè non e' direttamente visibile il carico della cpu. Questo succede quando il driver è listato sotto il kernel. In alcune circostanze la scrittura di parecchi GB potrebbe dare gli stessi risultati anche su FS diversi da NTFS.
Ad ogni modo per curiosità diamo un'occhiata al sito: http://ntfs-3g.org/support.html#cpu100
 
E.Romano
 
<< Inizio < Prec. 1 2 Pross. > Fine >>

Risultati 1 - 4 di 7