Experiencias DRBD Proxy / WAN

Me gustaría considerar el uso de DRBD para la replicación de datos entre una ubicación primaria y secundaria. El plan inicial es establecer un túnel VPN entre los dos; el extremo primario usando un segmento de un enlace T1 dual y la configuración de ubicación secundaria en una línea de cable / dsl.

El secundario existirá solo para DR: "nunca" se replicará de nuevo al primario.

¿Alguien ha hecho / cansado / usando algo como esto y cuáles son sus experiencias con él?

Linbit también tiene un producto Proxy DRBD (pago) que se supone que está diseñado para operar a través de enlaces de tipo WAN (compresión, pares múltiples). ¿Alguien ha intentado esto?

No puedo hablar por DRBD Proxy, pero a DRBD normal no le gustará tanto.

Incluso con una actividad limitada, puede saturar fácilmente un T1 dual (2x 1.5Mbps; para números redondos, 300KB / s). Se pueden tomar 300 KB / s solo mediante el registro de aplicaciones, y mucho menos hacer algo interesante en su servidor. Esto descarta la replicación síncrona ( Protocolo C ), y mucho menos agregar la latencia over-vpn a la ecuación.

La replicación asíncrona ( Protocolo A ) podría funcionar técnicamente, pero esperaría que la secundaria esté tan desactualizada como para no ser utilizable en caso de falla (la réplica puede estar atrasada durante el día)

La memoria síncrona ( Protocolo B ) no ayudará, ya que todavía está limitada por el problema del ancho de banda.

Espero que el Proxy DRBD siga sufriendo problemas similares, principalmente causando demoras en la replicación debido al ancho de banda limitado.

Le recomiendo que vuelva a evaluar su estrategia de DR para determinar contra qué está mitigando; falla de hardware o falla del sitio.

En el caso de la protección contra fallas en el sitio, puede obtener un mejor rendimiento de las transferencias de menor ancho de banda / mayor densidad en el caso de uno (o ambos) sitios restringidos de ancho de banda. Algunos ejemplos de esta técnica son rsync (las transferencias por cable se limitan a los cambios en los archivos entre ejecuciones, en lugar de por cambio para cada cambio, más algunos gastos generales de protocolo; se pueden ejecutar sobre SSH para cifrar y comprimir aún más el tráfico) y envío de registros de la base de datos (la transferencia de registros de bases de datos comprimidas para reproducir en la caja DR puede usar menos ancho de banda que transferir un volcado de base de datos completo).

Si está protegiendo contra fallas de hardware, una réplica DRBD local conectada con un crossover GigE funcionará bien, permitirá actualizaciones totalmente sincrónicas y permitirá la verificación en línea para demostrar que los datos son consistentes en ambos nodos. Aún puede combinar esta opción con una replicación de archivos limitada en un sitio de recuperación ante desastres para proteger contra un error del sitio primario.

DRBD-Proxy funcionará bien siempre que no esté saturando los enlaces T1 todo el tiempo. Enviamos muchos archivos de 2TB a través de una conexión DRBD-Proxy (otorgada con un enlace de 100 megabits) sin problemas. Siempre que tenga suficiente RAM para el proxy y la cantidad de escrituras no sea tan alta que su T1 no pueda hacer frente, esto debería funcionar bien. Sin embargo, desearía utilizar el modo asíncrono para la replicación.