Expériences DRBD Proxy / WAN

Je voudrais envisager l'utilisation de DRBD pour la réplication des données entre un emplacement principal et secondaire. Le plan initial est d'établir un tunnel VPN entre les deux; l'extrémité principale à l'aide d'une tranche d'une liaison T1 double et le paramètre d'emplacement secondaire sur une ligne câble / dsl.

Le secondaire n'existera que pour DR - il ne sera "jamais" répliqué sur le primaire.

Quelqu'un at-il fait / fatigué / utilisé quelque chose comme ça et quelles sont vos expériences avec cela.

Linbit possède également un produit (payant) DRBD Proxy qui est censé être conçu pour fonctionner sur des liaisons de type WAN (compression, plusieurs homologues). Quelqu'un a essayé ça?

Je ne peux pas parler pour le proxy DRBD, mais le DRBD ordinaire n'aimera pas autant.

Avec une activité même limitée, vous pouvez facilement saturer un double T1 (2x 1,5 Mbps; pour les nombres ronds, 300 Ko / s). 300 Ko / s peuvent être absorbés uniquement par la journalisation des applications, sans parler de faire quoi que ce soit d'intéressant sur votre serveur. Cela exclut la réplication synchrone ( protocole C ), sans parler de l'ajout de la latence over-the-vpn dans l'équation.

La réplication asynchrone ( protocole A ) pourrait techniquement fonctionner, mais je m'attendrais à ce que le secondaire soit tellement obsolète qu'il ne soit pas utilisable en cas d'échec (la réplique pourrait avoir des heures de retard pendant la journée)

La mémoire synchrone ( protocole B ) n'aidera pas car elle est toujours limitée par le problème de bande passante.

Je m'attends à ce que le proxy DRBD souffre toujours de problèmes similaires, entraînant principalement un retard de réplication en raison de la bande passante limitée.

Je vous recommande de réévaluer votre stratégie de reprise après sinistre pour déterminer ce que vous atténuez; défaillance matérielle ou défaillance du site.

Dans le cas de la protection contre la défaillance d'un site, vous pouvez obtenir un meilleur kilométrage avec des transferts de bande passante plus faible / de densité plus élevée dans le cas d'un site (ou des deux) limité en bande passante. Quelques exemples de cette technique sont rsync (les transferts over-the-wire sont limités aux changements de fichiers entre les exécutions - plutôt que par changement pour chaque changement - plus une surcharge de protocole; peut être exécuté sur SSH pour crypter et compresser davantage le trafic) et envoi de journaux de base de données (le transfert de journaux de base de données compressés à relire sur la boîte DR peut utiliser moins de bande passante que le transfert d'un vidage de base de données complet).

Si vous vous protégez contre les pannes matérielles, une réplique DRBD locale connectée à un crossover GigE fonctionnera très bien, permettra des mises à jour entièrement synchrones et permettra une vérification en ligne pour prouver que les données sont cohérentes sur les deux nœuds. Vous pouvez toujours combiner cette option avec une réplication de fichiers limitée vers un site DR pour vous protéger contre une défaillance du site principal.

DRBD-Proxy fonctionnera correctement à condition que vous ne saturiez pas les liens T1 tout le temps. Nous expédions de nombreux fichiers de 2 To via une connexion proxy DRBD (accordée avec un lien de 100 mégabits) sans aucun problème. À condition que vous ayez suffisamment de RAM pour le proxy et que la quantité d'écritures ne soit pas si élevée que votre T1 ne puisse pas le faire, cela devrait fonctionner correctement. Vous voudrez cependant utiliser le mode Async pour la réplication.