Newsgroup: it.comp.os.linux.sys
Titolo: DRBD per Disaster recovery VPS Asincrona

Ciao, sto testando una soluzione basata su Proxmox + DRBD.
Ho 3 nodi due dei quali in DRBD sincrono (c) un nodo solo x il quorum,
che non ospita vm e un nodo remoto sincronizzato via DRBD stacked 
Asincrono (A).
 
Direi che funziona :-) ma ho un dubbio,
nella modalit� Asincrona, in caso di terremoto e sprofondamento negli 
inferi del mio cluster principale, le Virtual machines diamo all'estero,
sincronizzate in modalit� Asincrona, saranno avviabili, non corrotte ?
Mi posso accontentare di averle anche allo stato diaciamo di una decina 
di minuti "vecchie" ma devono essere "integre", avviabili, senza errori 
di FS o simili ..
 
Nel mio caso le VM saranno piccole sui Debian 10/15G ( KVM ) e con poche 
variazioni, solo nel DB MySQL.
 
 
Ultima cosa, sapete se c'� modo di criptare via DRBD la comunicazione,
o mi tocca passare da una OpenVPN per forza ..
 
Grazie!
 
-- Yena --
 

 o mi tocca passare da una OpenVPN per forza ..
 
AFAICT no. Puoi usare openvpn con una crittografia leggera, magari a
64bit per non caricare eccessivamente gli host.
 
In ogni caso ti consiglio di usare comunque openvpn per via della
compressione lzo che puoi abilitare nella configurazione (drbd offre la
compressione nativa solo come feature a pagamento in drbd proxy).
Essendo drbd un sistema di replica a blocchi, la compressione ï¿œ molto
efficiente e puoi raggiungere rapporti di 3:1 e anche oltre con estrema
facilitï¿œ; questo significa poter ottenere un RPO inferiore della
soluzione di DR.
 
-- 
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

 soluzione di DR.
 
Info molto Utile, thanks
 
Posto le mie configurazioni ( ancora in testing ) che per ora sembrano 
andare bene .. se dovessere essere di ispirazione x qualcuno :-)
 
 
 
 
-----------------------------------------------------------------------------------------
resource r0 {
         protocol C;
         startup {
                 wfc-timeout  0;
                 degr-wfc-timeout 60;
                 become-primary-on both;
         }
         net {
                 cram-hmac-alg sha1;
                 shared-secret "my-secret";
                 allow-two-primaries;  #-> attivo su entrambi x live 
migration
                 after-sb-0pri discard-zero-changes;
                 after-sb-1pri discard-secondary;
                 after-sb-2pri disconnect;
 
				sndbuf-size 10M;
				rcvbuf-size 10M;
				ping-int 4;
				ping-timeout 4;
				connect-int 4;
				timeout 10;
				ko-count 5;
				max-buffers 128k;
				max-epoch-size 8192;
         }
         on proxmox-1 {
                 device /dev/drbd0;
                 disk /dev/sdb1;
                 address 
192.168.0.1:7788
;
                 meta-disk internal;
         }
         on proxmox-2 {
                 device /dev/drbd0;
                 disk /dev/sdb1;
                 address 
192.168.0.2:7788
;
                 meta-disk internal;
         }
 
           syncer {
                 c-plan-ahead 20;
                 c-min-rate 1M;
                 c-max-rate 70M;
                 c-fill-target 2M;
                 verify-alg md5;
                 al-extents 3389;
           }
}
-----------------------------------------------------------------------------------------
resource r0-U {
   protocol A;
 
   stacked-on-top-of r0 {
     device     /dev/drbd10;
     address    
192.168.1.135:7788
;
   }
 
   on proxmox-4 {
     device     /dev/drbd10;
     disk       /dev/sdb1;
     address    
192.168.1.212:7788
; # Public IP of the backup node
     meta-disk  internal;
   }
 
         syncer {
                         #replication speed
                         rate 512k;
 
                         #use compression for bitmap exchange
                         use-rle;
 
                         #set the "checksum-based synchronization" 
algorithm (usedwhen synchronizing)
                         csums-alg sha1;
 
                         #tunning the activity log size
                         #default is 127 ; increment it when using 
intensive I/O(write lot of small file)
                         al-extents 3389;
         }
 
}
----------------------------------------------------------------------------------------
 
 
-- Yena --
 

 andare bene .. se dovessere essere di ispirazione x qualcuno :-)
 
Non puoi usare una risorsa stacked sopra un dual primary. Been there, 
done that.
 
O aspetti drbd 9 o fai questa porcata agghiacciante:
 
http://lists.linbit.com/pipermail/drbd-user/2013-March/019781.html
 

 andare bene .. se dovessere essere di ispirazione x qualcuno :-)
 
Oltre a quanto detto da Cristian c'è un altro errore di fondo. Quando
usi drbd non è come usare uno shared storage, per cui la condizione di
split brain è molto più probabile e molto più critica.
 
Come indicato anche da Proxmox stessa in questa situazione è cosa buona
e giusta creare DUE risorse drbd (per esempio r1 e r2) e associarne una
ad un nodo del cluster e l'altra all'altro nodo. Quindi le macchine che
usano come storage r1 gireranno sempre sul nodo 1 mentre le macchine che
si appoggiano a r2 gireranno sul nodo 2.
 
Chiaramente puoi sempre migrare macchine da un nodo all'altro, ma lo
devi fare solo per necessità e possibilmente migrarle sempre tutte
insieme in modo che in caso di split brain che interessi drbd non debba
diventare matto a sincronizzare manualmente le cose con corrispondente
disservizio.
 
L'unica volta che proxmox mi ha dato problemi e mi ha fatto perdere dati
è stato proprio a causa di una situazione di questo tipo.
 
Inoltre in questo modo puoi far replicare in DR una risorse da un nodo e
l'altra risorsa dall'altro nodo distribuendo anche il carico elaborativo
della crittografia e compressione.
 
Leggiti attentamente la guida che spiega tutto.
http://pve.proxmox.com/wiki/DRBD
 



Perï¿œ da me funziona ... l'ho attivo in staging da una settimana :-)
Che problemi darebbe ?
 
Grazie!
 
-- Yena --
 


 
Thankss!
 
-- Yena --
 

 Che problemi darebbe ?
 
http://www.gossamer-threads.com/lists/drbd/users/22188#22188
 
 


Se non erro quindi funziona ma in caso di Fail di uno dei due nodi non 
Stacked ( principali, quelli Primary/Primary ) tocca rifare una 
resincronizzazione completa della risorsa remota.
 
Apparte questo non mi semba ci siano altri problemi... o sbaglio ?
 
-- Yena --

 -- Yena --
 
No, solo il nodo primary con la risorsa "stacked" manda le modifiche al 
sito di DR. Quelle del nodo primary SENZA la risorsa stacked finiscono 
nel Valhalla.
Leggi bene quel thread.
 
This can not work:
[ upper Primary node 1 ]------------------------------------------ [DR ]
[ lower Primary node 1 ]-----[ lower Primary node 2 ]
 
Because there is no way for writes from node2 to reach DR in this
picture, [DR] would receive only half of the writes, thus have a
corrupted dataset by design.
 
Quello che ï¿œ possibile fare ï¿œ questo:
[ upper Primary node 1 ] ---- [ upper Primary node 2 ]
[ lower DRBD node 1 ]
`------.[ DR node ]
 
Ma come han detto nel primo thread linkato questo setup ï¿œ una porcata, e 
all'epoca mi hanno consigliato di aprire un contratto di supporto prima 
di implementarla in produzione.
Poi i dati sono i tuoi, decidi tu.
 
Io aspetto DRBD 9 che lo fa nativamente


Visto che ho poche Virtual Machines, eliminerï¿œ la risorsa stacked e per
il disaster recovery monterï¿œ Idera su ogni VPS che sincronizza 
sull'altro datacenter ...
 
Non ï¿œ il massimo ma mi sa che sia + stabile ...
Sai mica quando uscirï¿œ DRBD9 stable ?
 
Grazie mille
 
-- Yena --
 

Il 30/09/2013 09:15, Cristian Mammoli ha scritto:

Ultima cosa, dimenticavo, quindi se mettessi su un architettura
Attivo -> Passivo
 
[ upper Primary node 1 ]------------------------------------------ [DR ]
[ lower Primary node 1 ]-----[ lower Secondary node 2 ]
 
Cosï¿œ funzionerebbe giusto ?
 
Se andasse giï¿œ il nodo Attivo,
potrei rendere primario il passivo (node 2),
e continuare la sincro sul DR da quello ...
 
 
-- Yena --
 
 


 
Yes, puoi fare 2 volumi DRBD di cui uno attivo sul nodo1 e uno attivo 
sul nodo 2. Cosï¿œ non hai una macchina che si gratta la pancia mentre 
l'altra fa tutto il lavoro.
Il problema ï¿œ che ti perdi la live migration delle vm

 Sai mica quando uscirï¿œ DRBD9 stable ?
 
No, per ora c'e' una prerelease ma non hanno dato date per il rilascio 
definitivo.
 


Ok quindi segue che con la Live migration
perdo l' HA automatico giusto ?
 
 
Grazie ancora
-- Yena --

 perdo l' HA automatico giusto ?
 
No, se uno dei nodi muore l'altro promuove il volume drbd in primary e 
fa ripartire le vm li.
Come implementi l'ha pero dipende da te: pacemaker, rhcs ecc
 
La live migration ha come prerequisito quello di accedere in RW al disco 
virtuale della VM da entrambi i nodi durante la migrazione.
Di conseguenza senza dual primary non la fai
 


Per curiositï¿œ ho testato una live Migration avanti ed indietro
nella configurazione NON supportata.
Cercando poi di avviare il VPS nella macchina DR (remota), questa 
risulta effettivamente corrotta...
 
-- Yena --

 -- Yena --
 
Per fortuna hai chiesto :)


Yess :-))
 
-- Yena --