consiglio cluster debian

[divertiamoci.insieme]

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]

un po di documentazione c'e'

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

[eclissi83]

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]

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]

Originariamente inviato da divertiamoci.insieme

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]

Che vantaggi ha keepalived rispetto ad heartbeat?

[eclissi83]

Originariamente inviato da dennyv

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]

Originariamente inviato da eclissi83

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]

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]

c'è qualche modulo di Rsync per webmin? Sincronizza anche i file di mysql?
Posso dire di sincronizzare ogni ora?

Grazie

[eclissi83]

Originariamente inviato da divertiamoci.insieme

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]

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]

Originariamente inviato da divertiamoci.insieme

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]

La prossima settimana vi faro sapere qualche cosa. Attendo i due server presi in parti diverse.