[MontelLUG] R: Opinione su db open source per cluster

[Nunziante]

Saluti e buon ferragosto a tutti.
Vi leggo sempre con piacere e vi ringrazio per tutto quello che riesco ad 
apprendere dai vostri discorsi.

Ora vi faccio una domanda alla quale spero che qualcuno di voi potrà 
rispondermi.

Durante il servizio di Help telefonico cui partecipo, mi è stata posta una 
domanda alla quale credo ci sia una soluzione anche se non la conosco.

Una rete lan: un certo numero di computer sono stati messi in rete, si 
vedono normalmente tra loro e si possono usare in scrittura e lettura tutti 
i contenuti delle cartelle condivise.

Le varie unità della rete sono dislocate in un palazzo di vari piani. Anche 
sullo stesso piano i computer sono dislocati in stanze diverse.

A causa di questa distribuzione estesa ed essendo necessario usare la posta 
elettronica in assenza di connessione ad Internet, come si può gestire la 
posta elettronica?

Se, come penso, si deve installare un server di posta, come si può fare?

Ciao.

Nunziante.

-----Messaggio Originale----- 
Da: "Samuele Zanin" <samuele.zanin a tiscali.it>
A: "Lista generale del MontelLUG" <montellug a montellug.it>
Data invio: lunedì 11 agosto 2008 12.56
Oggetto: Re: [MontelLUG] Opinione su db open source per cluster


Daneel Olivaw wrote:
> Se non sbaglio dovrebbe esserci anche un sistema per cui se va giù un
> server l'altro/gli altri se ne accorgoni e si prendono in carico il
> lavoro in maniera trasparente per gli utenti, ma non vorrei dire
> scemate.
Il fatto che quando un nodo va giù e il suo posto viene preso da un'altro,
gli utenti non si accorgano di nulla, dipende principalmente dal tipo di
applicazione.
Se per esempio hai in cluster il server che ospita un sito web con pagine
statiche, la cosa per l'utente finale è completamente trasparente.
Nel mio caso ad esempio il servizio di iscsi target che esporta i vari LUN
se configurato senza bufferizzazione, in caso di take over, dovrebbe essere
trasparente per il client che accede al servizio (da quello che scrivono su
internet).
Nella pratica però ho un problema che quando heartbeat tira su l'indirizzo
di rete virtuale sull'altro nodo e poi manda il comando per variare la cache
arp nei vari client, nel mio caso il client si incavola e si
disconnette/riconnette creando problemi. Se invece faccio lo start/stop del
servizio sullo stesso server non si accorge di nulla.
Dovrei trovare il modo per virtualizzare anche il mac-address, vediamo se
con lo spoofing riesco a combinare qualcosa.

Alla fine, dipende se il servizio che gira sul cluster, tiene in memoria
delle informazioni che non possono essere replicate sull'altro nodo.
Nel caso di un server sql, ad esempio, tu stabilisci una connessione, invii
un comando al server che può essere ad esempio una select su una tabella e
questo comincia a restituirti i dati; se stacchi la spina del server, tutte
le informazioni relative all'esecuzione del programma (variabili in memoria,
punto di esecuzione del programma ecc.) vengono perse.
Perché la cosa sia completamente trasparente, dovresti mirrorare anche il
contenuto della ram e sincronizzare le cpu dei due nodi, nonché tutte le
altre periferiche. Da quello che so io sui server classici con architettura
x86 non mi risulta possibile una cosa del genere. Non so se invece su altre
macchine tipo AS400 e similari che derivano dai mainframe la cosa sia
fattibile.

Più in generale, il discorso dell'alta disponibilità, non riguarda il fare
in modo che un servizio non subisca mai interruzioni, ma che il servizio sia
diponibile per il maggior tempo possibile e di conseguenza che le
interruzioni siano le più brevi possibili.

In particolare, la cosa che dal mio punto di vista è fondamentale in certi
ambienti è che qualsiasi cosa accada non ci sia una perdita di dati.
Alla fine, poco importa se l'applicazione va in errore perché casca la
connessione con il db. Se l'applicazione è scritta come si deve, basta che
tenti di ristabilire la connessione e riprenda da dove era stata interrotta.

Per il discorso dati, la cosa varia a seconda di cosa devi fare.
Se hai un file server, può bastare che tu metta uno script ad esempio con
rsync che ogni x minuti risincronizza le due macchine.
Nel caso invece di un database server, qui i data file vengono lockati dal
servizio del database all'avvio e poi rilasciati quando si ferma il
servizio, servizio che in molti casi rimane in piedi per mesi senza subire
riavvii.
Alcuni database server permettono di effettuare backup a caldo (mentre gli
utenti stanno usando il db), solo che questa operazione è lunga e può
rallentare in modo più o meno pesante il server, quindi la si fa una o due
volte al giorno.
Ad esempio nel caso di Sql Server, questo ti permette di utilizzare una
tecnica che si chiama "log shipping" con la quale si fa un backup iniziale,
dopo di che ad intervalli regolari di n minuti (10, 5 ecc), si lancia un
comando che fa il backup su un file delle sole transazioni eseguite
dall'ultimo backup, e vengono applicate al database che è in sola lettura
sull'altra macchina.
Questo meccanismo ti permette di ridurre al minimo il rischio di perdita di
dati, ma c'è sempre un rischio.
Immaginati ambienti tipo banche o fabbriche dove devono essere memorizzati i
vari dati di produzione  dei prodotti per questioni di tracciabilità.
In ambienti grossi, per ovviare a questi problemi, utilizzano dei SAN, che
però da quello che sono costosi, ma senza "single point of failure".

Per fortuna, esiste drbd che permette di replicare i dati tra due server in
modo trasparente per le applicazioni che ci stanno sopra. Poi esportando il
volume tramite iscsi, riesci a renderlo disponibile a chiunque sia in grado
di supportare quel protocollo, sia esso linux, windows o particolari schede
hardware (hba) che vengono viste all'interno del server come un normale
controller disco.

Il brutto della cosa è che mentre una volta tutte le informazioni inserite
dentro ad un pc avevano pari pari un backup su carta, e quindi in caso di
problemi si potevano recuperare le informazioni, al giorno d'oggi il
passaggio su carta tende ad essere saltato rendendo sempre più un requisito
essenziale garantire la perfetta conservazione delle informazioni su
supporto digitale.

> Ah, beh, parafrasando un famoso detto, "Neanche gli dei possono nulla
> contro i CL" :-)

Il bello è che molte volte gli utenti non si rendono conto di questa cosa e
considerano il server immortale. Due cose successe martedì e mercoledì.
Martedì vado da un cliente in quanto vuole che vada a dargli una controllata
al programma che è lento, leeento ecc. Vado li pensando di dover fare il
solito controllo delle procedure che usano più di frequente e vedere se c'è
qualche indice da ottimizzare. Controllo i piani di esecuzione delle query e
sono ok, effettivamente è a tratti un po' lento. Proviamo a vedere se è il
caso il caso di deframmentare il disco. Il grafico del disco è una striscia
rossa. Bon, liberiamo un po' il disco e dopo lanciamo la deframmentazione.
Comincio a spostare un po' di backup da un'altra parte per una 10ina di
giga, tempo residuo 40 minuti. Il solito windows che non stima i tempi
giusti. Dopo qualche minuto guardo se ha finito. Ancora 40 minuti. Qua c'è
qualcosa che non va, e intanto nella mia mente si fanno strane fantasie.
Vado davanti al server, apro lo sportello davanti e... bingo. Spia rossa su
uno dei 3 dischi in raid 5. Dallo strato di polvere, lo sportello dei dischi
non doveva essere stato aperto da un bel pezzo. Ho chiesto da quanto avevano
notato rallentamenti, mi hanno detto da una decina di giorni. Guardo sulla
console, e c'è lo script di backup sullo snap server bloccato da chissà
quando. Le copie su nastro... booh. Per fortuna da questo cliente per
l'hardware/sistemistica si occupa un'altra ditta. Intanto il disco nuovo non
arriverà fin dopo le ferie. Yahooo.

Mercoledì, invece ero da altro cliente che mi ha fatto unificare database e
altri dati presenti su due server distinti. In più mi aveva chiesto di
controllare anche i backup in quanto sembrava non venissero fatti (questi
qui hanno il server dentro ad un ufficio che ha la porta che comunica con la
falegnameria, vi lascio immaginare cosa c'è dentro l'unità dat, sono 4 anni
che gli dico che quel server non deve essere li, ma non vogliono sapere di
spostarlo. Hanno acquistato il gruppo di continuità dopo avere sostituito 4
o 5 alimentatori del server). Faccio tutto quello che c'è da fare e alla
fine i dati effettivamente non ci stanno sul dat che è da 20 gb.
Comincio a vedere se per caso c'è qualche copia di copia di file inutile da
ecludere dal backup, quando l'occhio salta su una cartella imboscata in
mezzo a quelle con i dati che si chiama "pps" e poi "xxx". Na caterba de
file, e anca grossi dai nomi più fantasiosi.
Alla fine dei conti 8.9 GB tra pps e avi di pornazzi vari che venivano
backuppati su dat al posto dei dati di lavoro.
Un collega mi ha detto che ha dovuto riformattare più volte il portatile
dell'ex titolare in quanto infestato da virus e ci aveva trovato di tutto,
il che spiegherebbe perché siano finiti sul server.




_______________________________________________
montellug mailing list
montellug a montellug.it
http://mail.montellug.it/mailman/listinfo/montellug_montellug.it