PDA

View Full Version : consiglio cluster debian


divertiamoci.insieme
08-10-2010, 02:20
Mi servirebbe un consiglio. Dovrei realiazzare un cluster su server reali dove su ognuna di queste verrà montata vmware server. I SO virtualizzati sanno 2 debian. Che mi consigliate per fare la custerizzazione o la sincronizzazione? Saranno dei server web come faccio a sapere se un servizio è su o meno? Qualcuno mi sa suggerire una buona guida?

sacarde
08-10-2010, 09:44
un po di documentazione c'e'

http://www.google.it/search?q=linux+cluster+ha&ie=UTF-8&oe=UTF-8

eclissi83
08-10-2010, 16:15
uhm... invece di fare un cluster dell'intera macchina, perche' non provi a fare in modo che i servizi siano in HA? da quello che ho capito ti serve che i servizi siano su anche in caso di failure hardware.
per fare cio' ti consiglio di usare demoni come keepalived, un po' ostico da configurare ma funziona bene.
devi solo prestare attenzione ad avere i dati sincronizzati tra le due macchine.

ciao

divertiamoci.insieme
08-10-2010, 23:24
ci do uno sguardo e vi faccio sapere.
Avete qualche guida per la configurazione di keepalived? keepalived sincronizza tutta la macchina oppure ho problemi con la sincronizzazione del db?

eclissi83
09-10-2010, 01:42
ci do uno sguardo e vi faccio sapere.
Avete qualche guida per la configurazione di keepalived? keepalived sincronizza tutta la macchina oppure ho problemi con la sincronizzazione del db?
keepalived non sincronizza nulla.. fondamentalmente keepalived si "palleggia" gli indirizzi IP tra le macchine.
in pratica il funzionamento, a parole povere, e' questo:
SCENARIO:
- 2 server gemelli, "main" e "backup" (stessi servizi avviati, stesse configurazioni stessi dati)
- 1 IP virtuale da poter "spostare" in caso di failure di uno dei server
- 1 interfaccia per server dedicata alla verifica della "salute" dei server
FUNZIONAMENTO:
- keepalived esegue un polling ogni X secondi
- se il polling restituisce un numero Y di errori sul server "main", keepalived si preoccupa di alzare l'IP virtuale sul server "backup"
- i servizi sono ora disponibili su "backup".

Il primo problema che si pone e' la sincronizzazione dei dati: come affrontarlo?
Ci sono varie soluzioni:
- storage di rete ridondato
- file system distribuito tra i due server drbd
- rsync "differito" dei dati
La scelta e' dettata dai costi e dalla "semplicita'" di implementazione che si vuole avere...

ciao

dennyv
10-10-2010, 17:38
Che vantaggi ha keepalived rispetto ad heartbeat?

eclissi83
10-10-2010, 21:01
Che vantaggi ha keepalived rispetto ad heartbeat?
keepalived lo puoi usare anche come bilanciatore di carico per un determinato servizio scegliendo quale nodo del cluster usare in base alle priorita' impostate, cosa che mi pare che heartbeat non faccia...

ciao

divertiamoci.insieme
12-10-2010, 01:03
Il primo problema che si pone e' la sincronizzazione dei dati: come affrontarlo?
Ci sono varie soluzioni:
- storage di rete ridondato
- file system distribuito tra i due server drbd
- rsync "differito" dei dati
La scelta e' dettata dai costi e dalla "semplicita'" di implementazione che si vuole avere...

ciao

intanto grazie a tutti.
Potremmo analizzare quale sono i vantaggi e gli svantaggi?
Quando parliamo di storage di rete ridondato sarebbe il NAS? Uno o due NAS ?

eclissi83
12-10-2010, 16:50
Storage Ridondato: SAN (i NAS sono lenti) con hw ridondato
Pro:

Alte prestazioni con fiber channel
Alta affidabilita'
Possibilita' di inserire N server usando lo stesso storage
Trasparente all'utente che deve solo fare il mount della LUN configurata
Recovery automatico in caso di rottura di uno dei dischi
Indipendente dalla configurazione di rete

Contro:

Costo elevato apparato di storage
Acquisto di almeno due schede in fiber channel

DRBD: File system condiviso tra due server
Pro:

In mainline del kernel dal 2.6.33
Usabile su LVM o come unita' fisica per LVM
Scritture sincrone o asincrone configurabili
Integrato con Heartbeat
Recovery efficace

Contro:

Dalla mia esperienza non risulta stabilissimo
Usabile solo con 2 server + 1 di spare (opzionale)
Legato ai file system GFS/OCFS2
Velocita' di sincronizzazione legata alle prestazioni di rete

Rsync: sincronizzazione dati
Pro:

Facilta' di implementazione
Nessun recovery necessario in caso di failure di uno dei nodi
Indipendente dalla configurazione delle partizioni e dei sistemi

Contro:

Replica asincrona dei dati
Ogni nodo di replica contiene tutti i dati della sorgente
Velocita' di sincronizzazione legata alle prestazioni di rete

divertiamoci.insieme
17-10-2010, 01:53
c'è qualche modulo di Rsync per webmin? Sincronizza anche i file di mysql?
Posso dire di sincronizzare ogni ora?

Grazie

eclissi83
17-10-2010, 02:36
c'è qualche modulo di Rsync per webmin? Sincronizza anche i file di mysql?
Posso dire di sincronizzare ogni ora?

Grazie
da una ricerca veloce (meno di un minuto) pare che ci sia il modulo rsync per webmin, ma non ti crea lo script per il backup, ti fa configurare il demone rsyncd.
per quanto riguarda il backup del db, l'eventuale rsync che faresti della directory dove son i file di mysql non sarebbe fruibile correttamente: la soluzione e' quella di effettuare i dump del db tramite il comando mysqldump.

ciao

divertiamoci.insieme
25-10-2010, 01:02
Forse a questo punto devi vedere se posso creare n script che faccia il recovery previsto da webmin in questo caso dovrei riuscire a mantere ad esportare tutto in modo completo. Certo c'è sempre il problema che dovrei esportare tutto e non posso fare un incrementale. Che mi consigliate?

eclissi83
25-10-2010, 13:57
Forse a questo punto devi vedere se posso creare n script che faccia il recovery previsto da webmin in questo caso dovrei riuscire a mantere ad esportare tutto in modo completo. Certo c'è sempre il problema che dovrei esportare tutto e non posso fare un incrementale. Che mi consigliate?
ciao,
non usando webmin non so proprio dirtelo. l'unica cosa che non faresti incrementale, pero', e' il db e se ti preoccupi dello spazio occupato per i backup puoi sempre conservartene che ne so, 10-15 e poi ruotarli...

ciao

divertiamoci.insieme
31-10-2010, 09:31
La prossima settimana vi faro sapere qualche cosa. Attendo i due server presi in parti diverse.