Esperienze proxy / WAN DRBD

Vorrei considerare l'uso di DRBD per la replica dei dati tra una posizione primaria e una secondaria. Il piano iniziale è quello di stabilire un tunnel VPN tra i due; l'estremità primaria utilizza una porzione di un doppio collegamento T1 e l'impostazione della posizione secondaria su una linea cable / dsl.

Il secondario esisterà solo per DR - non "si" replicherà mai sul primario.

Qualcuno ha fatto / stanco / usando qualcosa del genere e quali sono le tue esperienze con esso.

Linbit ha anche un prodotto proxy (a pagamento) DRBD che dovrebbe essere progettato per funzionare attraverso collegamenti di tipo WAN (compressione, più peer). Qualcuno l'ha provato?

Non posso parlare per il proxy DRBD, ma al normale DRBD non piacerà molto.

Con un'attività anche limitata, è possibile saturare facilmente un doppio T1 (2x 1,5 Mbps; per numeri arrotondati, 300 KB / s). 300 KB / s potrebbero essere occupati solo dalla registrazione delle applicazioni, per non parlare di fare qualcosa di interessante sul server. Questo esclude la replica sincrona ( protocollo C ), per non parlare dell'aggiunta della latenza over-the-vpn nell'equazione.

La replica asincrona ( protocollo A ) potrebbe tecnicamente funzionare, ma mi aspetto che il secondario sia così obsoleto da non essere utilizzabile in caso di guasto (la replica potrebbe essere indietro di ore durante il giorno)

La memoria sincrona ( Protocollo B ) non aiuta in quanto è ancora vincolata dal problema della larghezza di banda.

Mi aspetto che il proxy DRBD soffrirà ancora di problemi simili, causando principalmente un ritardo della replica a causa della larghezza di banda limitata.

Ti consiglio di rivalutare la tua strategia di DR per capire cosa stai mitigando; errore hardware o errore del sito.

In caso di protezione contro i guasti del sito, è possibile ottenere un chilometraggio migliore da una larghezza di banda inferiore / trasferimenti di densità più elevata nel caso di uno (o entrambi) siti con vincoli di larghezza di banda. Alcuni esempi di questa tecnica sono rsync (i trasferimenti over-the-wire sono limitati alle modifiche dei file tra le esecuzioni - piuttosto che per ogni modifica per ogni modifica - oltre ad alcune spese generali del protocollo; può essere eseguito su SSH per crittografare e comprimere ulteriormente il traffico) e invio del registro del database (il trasferimento dei registri del database compresso per la riproduzione nella casella DR può utilizzare una larghezza di banda inferiore rispetto al trasferimento di un dump del database completo).

Se stai proteggendo da guasti hardware, una replica DRBD locale collegata con un crossover GigE funzionerà perfettamente, consentirà aggiornamenti completamente sincroni e consentirà la verifica online per dimostrare che i dati sono coerenti su entrambi i nodi. È ancora possibile combinare questa opzione con una replica limitata dei file in un sito DR per proteggersi da un errore del sito primario.

DRBD-Proxy funzionerà perfettamente a condizione che non si saturi continuamente i collegamenti T1. Spediamo molti file da 2 TB attraverso una connessione DRBD-Proxy (garantita con un collegamento da 100 megabit) senza problemi. Se hai abbastanza RAM per il proxy e la quantità di scritture non è così alta che il tuo T1 non può farcela, dovrebbe funzionare bene. Tuttavia, si desidera utilizzare la modalità asincrona per la replica.