Newsgroup: it.comp.virtualizzazione
Titolo: Re: Gestione 2 host con Proxmox

 Altri consigli e/o idee?
 
drbd
 
 
-- 
In God we trust. All others must bring data
W. E. Deming

 fatto prove e volevo essere sicuro...
 
Si beh va configurato ovviamente, comunque ho una installazione simile
alla tua e sto usando drbd su due schede dedicate per le VM critiche.
Per adesso nessun problema.


 Come bisognerebbe muoversi in questo caso?
 
Con tutte le VM spostate direi che potresti stoppare drbd, mettere host1
fuori linea, reinstallare il tutto e prima di riconnettere il
collegamento LAN fra i due host darei un invalidate remote dall'host2 e
invalidate local dall'host1. Comunque per mettere le terga a paratia un
backup delle VM lo farei :)


 
 
Quantomeno fai una backup della VM su un disco esterno visto che i
backup periodici non funzionano (che � MALE).

 � che dispensi tantissime informazioni...
 
Anch'io volevo usare drdb e ho avuto qualche difficolt�.
 
Poi, visto che la NAS ce l'avevo, ho usato la soluzione NFS che � per
bimbi scemi. :)
 
Per� se qualcuno l'ha gi� fatto e ci spiega per bene drdb non sarebbe male.
 
saluti non documentati
-- 
E' una truffa, non � una crisi:
http://dottormistero.blogspot.it/2012/05/ma-cose-questa-crisi.html
 

Personalmente con la nuova versione non ho avuto problemi a fare il 
DRBD, la live migration ed ha.
Le uniche guide che ho seguito sono queste:
 
http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
 
http://pve.proxmox.com/wiki/DRBD
 
http://pve.proxmox.com/wiki/Fencing
 
http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster
 
http://pve.proxmox.com/wiki/High_Availability_Cluster
 

 proxmox?
 
Vedi il post di Beppe


 Grazie a te e a Beppe, e scusate la niubbaggine.
 
Figurati! Siamo (ci sono anch'io) tanti niubbi

 cat: /proc/drbd: No such file or directory
 
Niente drbd ma a questo punto, avendo tu chiarito che non hai spazio
aggiuntivo, sconsiglierei di utilizzarlo.
Ti basta una migrazione offline? Se vuoi HA � obbligatorio avere uno
storage shared.


 abbastanza liberamente...
 
S� la creazione della nuova partizione per il DRBD � distruttivo, mi 
dispiace...
 
Fossi nella tua situazione procederei cos�:
1. preparazione del nuovo server (host2): DRBD attivo e tutto il resto 
ben configurato, in quel caso ti vedr� soltato un nodo ma se tutto � ok 
puoi creare e far lavorare le VM senza problemi.
2. backup delle VM dal vecchio host1
3. copia/restore delle VM sul nuovo host2
4. shutdown del vecchio host1 (le VM sono ora su host2)
5. installazione/configurazione/update del vecchio host1 alla nuova 
versione dovresti trovarti in una situazione ideale.
 
L'unico problema � che la sincronizzazione del DRBD potrebbe metterci un po'
 

 
Allora ci vuole HA

 prestazioni certo non sarebbero il massimo)...
 
Pi� che delle prestazioni mi preoccuperei del fatto che il NAS
diventerebbe un single point of failure per cui vanificheresti lo sforzo
di creare un high availability cluster.

 Grazie, ciao.
 
Di nulla!

 quanto su un Host fisico e poi rimettere in synch drbd.
 
Se puoi fare rapidamente il collegamento col NAS spostare le VM �
semplice. Crei uno storage sul NAS e lo marchi non condiviso, stoppi le
VM e fai una migrazione offline, riavvii le VM, fine.


 
Si pu� anche senza spianare:
 
http://lists.linbit.com/pipermail/drbd-user/2009-February/011464.html
 
 
Per� ti consiglio di partire da zero, cos� avrai una configurazione 
pulita e potrai seguire pedissequamente la guida.
 
Comunque DRBD richiede una partizione o un volume dedicato e l'installer 
di default di Proxmox non ti permette di partizionare. Di conseguenza o 
installi Debian con partizionamento manuale e poi installi Proxmox 
oppure (meglio) fai creare al tuo controller raid 2 drive group, sul 
primo (una manciata di GB) installi proxmox e il secondo lo usi come 
backend per drbd.
 
hth
 
-- 
BOFH excuse #145:
 
Flat tire on station wagon with tapes.  ("Never underestimate the 
bandwidth of a station wagon full of tapes hurling down the highway" 
Andrew S. Tannenbaum)

 Ho provato con una debian fresca e funziona...
 
Beh questo � positivo. Prima di tutta l'operazione devi per� creare la
partizione su host2 da dedicare a DRBD (e da creare poi su host1),
installare drbd e configurarlo.
 

 intanto mi guardo meglio la documentazione...
 
Split brain non direi visto che le VM sono sul NAS.
Rifai la procedura e sposti le VM dal NAS sullo storage drbd.
 

 Sbaglio?
 
Corretto.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 Considerazioni ulteriori?
 
Giusto.
In ogni caso teniamo conto che, a prescindere dai problemi di HA, se per
qualche malfunzionamento della VM o del disco fisico (assai pi�
probabili dei quasti alla NIC o allo switch) i dati si corrompono, DRBD
li copia allegramente causando un crash generale. Questo per dire che la
sicurezza assoluta non esiste e che il backup ci vuole sempre e comunque.

 sicurezza assoluta non esiste e che il backup ci vuole sempre e comunque.
 
Il backup � un dato di fatto da quale non si pu� prescindere, siamo
daccordo.
In ogni caso i miei due Host hanno hardware completamente ridondato e
pu� esserci un down del server non tanto per un disco rotto, quanto per
un failure totale della macchina.
Mi � successo per esempio con uno di questi due, per la rottura della
backplane.
Ma in casi come questi drbd assolve al suo compito continuando a
funzionare sull'altro nodo.
Se le VM sono sul aperte sul nodo morto sono ferme ma possono essere
tirate su dall'altro che funziona e che ha dati per lo meno consistenti
a prima del fault del nodo principale.
L'importante � non far riavviare automaticamente le VM sul nodo che era
morto quando torna su...
 
Almeno la teoria mi dice questo, qualcuno che ha piu esperienza di me
potrebbe confermare la cosa o smentirmi...
 
-- 
Giocare col mondo, facendolo a pezzi...
Bambini che il sole, ha ridotto gia'... vecchi.

 potrebbe confermare la cosa o smentirmi...
 
Sarebbe interessante sentire altre opinioni.

 potenzialmente distruttive:
 
Ci si pu� trovare se configuri drbd con il culo o fai il cluster senza 
fencing (il che � impossibile)
 
 
 
 
-- 
BOFH excuse #190:
 
Proprietary Information.

 o fai il cluster senza fencing (il che ï¿œ impossibile)
 
Nulla ï¿œ impossibile... basta avere abbastanza inventiva. :)



 
Si, anche io uso /bin/true come fence agent in test ma farlo in 
produzione ï¿œ masochismo ^_^
 
-- 
BOFH excuse #188:
 
..disk or the processor is on fire.

 
https://alteeve.ca/w/Obliterate-peer.sh_(DRBD_fence_handler)
 
 
Il problema ï¿œ che non sempre puoi avere un fence device e non ï¿œ una
questione di costi ma di possibilitï¿œ fisica.
 
Io per esempio ho risolto semplicemente con l'attenzione.
Ho due drbd e tutte le macchine di r0 vanno sul nodo 1 mentre tutte
quelle su r1 vanno sul nodo 2. Se le sposto le sposto insieme per
evitare che in caso di SB debba fare attivitï¿œ manuale.
E poi un monitoraggio del drbd... non si puï¿œ far molto di piï¿œ senza fencing.
