linux user group brescia

dìvide et ìmpera !

il mito di una roba che fa tutto bene e lavora al posto tuo ...

il contro e', come faccio adesso, avere tutta una serie di tool e di sistemi
per ottenere un risultato che alla fine e' complesso,
nell'insieme dei suoi semplici strumenti, da tenere aggiornato, sopratutto
in testa ( la MIA testa )
mi ricordo che mi sconsigliasti di mettere gli OID nel db
non ti ho dato ascolto, aime'

al brindisi volevo gia' venire, se non inviti anche l'erlug e poi ci
troviamo tutti a mantova
..e son convinto che conosci qualcuno anche piu' a sud

ciao
furio

Il giorno 21 dicembre 2010 15:26, Andrea Gelmini
<andrea.gelmini a lugbs.linux.it>ha scritto:

> Il 21 dicembre 2010 12:20, Furio Settimi <furio.settimi a gmail.com> ha
> scritto:
> > dalla lista speravo che uscisse un commento proveniente da un'esperienza,
> > magari qualcosa di non documentato
>
> Oddio, l'argomento è complicato e spinoso, proprio perché non esiste
> una soluzione definitiva,
> in quanto ogni singola realta' ha le sue peculiarita'.
> Io, tipicamente, sono per l'utilizzo di strumenti rozzi e semplici.
> Tieni presente che, come regola generale, più la soluzione è
> complessa, più richiede tempo/skill, soprattutto nel caso di disaster
> recovery (che è l'aspetto, in questi casi, su cui fare tutte le prove
> del caso prima di andare in produzione).
>
> Ti butto lì un po' di idee, ma possono essere totalmente sbagliate,
> visto che io non conosco in dettaglio le tue esigenze, carichi di
> produzione, ecc:
> a) due server, sul primo tieni tutto, il secondo diventa solo gemello;
> b) non usi una singola soluzione di ridondanza (tipo drdb, che è
> notevole e robusto, ma che ti toglie della liberata' di azione), bensì
> lavori sulle singole soluzioni;
> c) con postgresql smetti di fare i dump, e usi semplicemente il log
> shipping che ti offre da parecchie versioni (così non devi neppure
> upgradarlo). Ottiene backup costanti e completi fino alla singola
> transazione, che puoi comodamente rsyncare/copiar;
> d) per i dati degli utenti, mail, ecc, te la giochi agile con rsync et
> affini. In questo modo hai sempre la possibilita' di agire sul singolo
> dato (posso volere il disaster recovery, ma più frequentemente può
> servirmi recuperare la singola mail/file);
> e) usi un filesystem che ragioni a snapshot, così hai il backup
> costante senza procedure aggiuntive anche in termini di secondi;
> f) ti resta il problema del backup geograficamente distribuiti. Qui si
> può inventare qualsiasi cosa. A seconda di quanti dati nuovi generi al
> giorno, puoi pensare a delle soluzioni online, oppure a un po' di
> dischi esterni da tenere in rotazione. Ogni disco lo usi come raid, in
> modo da syncare solo le parti effettivamente modificate.
>
> Starei lontano da soluzioni multi master, sia per i DB che per i
> filesystem.
> Sono cose interessanti e molto utili, ma se non ci hai a che fare
> tutti i giorni, ti espongono a errori/rischi (a me pare) dei quali
> puoi fare a meno.
> Ora, non è mai carino fare nomi, ma se vieni al brindisi possono
> raccontarti di realta' veramente grosso dove, malgrado un presidio
> costante, ad un certo punto tutti i nodi multi-master decidono di
> dover operare per i fatti loro...
>
> Tieni inoltre presente che soluzioni semplici ti permetto di pilotare
> con comodo chiunque sia dall'altra parte (tu in ferie in Guatemale, e
> la segretaria con diploma CEPU dall'altra).
>
> Inoltre, eventuali finestre di tempo di fermo, possono cambiare di
> molto il tutto.
> Se so che nella notte posso fermare i servizi oppure che sono attivi,
> ma non utilizzati, è possibile rendere il tutto ancora più semplice.
>
> Sbattendosi un po' di più (e se la situazione è sufficientemente
> stabile) puoi pensare a una replica dei servizi su dischi
> USB/esata/sfigati (agevolemente collegabili ovunque) su cui replicare
> solo i dati.
>
> Succede qualcosa, connetti il tutto alla prima macchina e buonanotte.
> Ovvio, questo significia un'attenta gestione delle modifiche degli
> stessi.
>
> Dicevo, se vieni al brindisi ne discutiamo.
>
> Di mio mi sento di suggerirti, comunque, di dare precedenza alle
> soluzioni più semplici.
>
> Ciao,
> Gelma
>
> --
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lugbs.linux.it/pipermail/lug/attachments/20101221/e340f088/attachment.html>