Skip to main content
Knowledge Base
linbit.com linbit.com Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Knowledge Base Topics
  2. /
  3. DRBD
  4. /
  5. DRBD Proxy
  6. /
  7. When to Use DRBD Proxy

When to Use DRBD Proxy

DRBD® provides real-time block-level replication, that while created for high availability use cases, is also suitable for stretched clusters and other disaster recovery use cases. However, when replication traffic has to travel over WAN links with limited or inconsistent bandwidth, DRBD might experience bottlenecks which can affect the performance of applications that rely on DRBD replicated data. DRBD Proxy can improve the performance and stability of such applications during times when write I/O is peaking.

This article explains the role of DRBD Proxy, and tells you how to determine when it is necessary and how to deploy it effectively.

What DRBD Proxy does

DRBD Proxy compliments and enhances DRBD by improving replication behavior over constrained WAN connections. It provides the following features:

  • Write buffering: Temporarily stores replicated write operations in RAM to absorb bursts in replication traffic that would otherwise overwhelm the WAN and cause I/O to temporarily block.
  • Compression: Reduces the volume of replication data transmitted over the WAN by using Zstandard compression.
  • Encryption: Supports DRBD kTLS encryption to secure replication traffic without relying on external tools such as stunnel or WireGuard.
  • Automatic recovery: Flushes buffered replication traffic after WAN outages, and resumes replication after the connection is restored.
  • Improved performance: Version 4 of DRBD Proxy is written in Rust and uses Linux io_uring for improved kernel queuing and lower CPU usage.

Determining when you need to use DRBD Proxy

To determine if DRBD Proxy is required, you need to assess whether your WAN link can accommodate your application’s peak write activity. You can use the following decision matrix to help:

Workload Pattern Recommended Solution Reason
Sustained writes never exceed WAN bandwidth DRBD (protocol A) No need for additional tools if replication traffic is consistently manageable.
Occasional bursts exceed bandwidth DRBD Proxy (buffering only) Proxy absorbs temporary spikes and sends data when bandwidth becomes available.
Occasional bursts exceed bandwidth unless compressed DRBD Proxy (buffering + compression) Compression enables large bursts to fit within WAN limits.
Frequent bursts exceed bandwidth when compressed and prevent Proxy buffer from flushing completely Asynchronous backups Real-time replication is not feasible. Use scheduled snapshot transfers instead.
Sustained writes exceed WAN bandwidth constantly Asynchronous backups Real-time replication is not feasible. Use scheduled snapshot transfers instead.

How to evaluate your environment for a DRBD Proxy use case

Take the following steps to gather measurements that can help you determine whether you need DRBD Proxy:

  1. Measure I/O write behavior: Collect I/O stats over multiple days. Note average throughput and peak bursts, for example, traffic bursts in the 99th percentile.
  2. Test WAN bandwidth: Measure real-world throughput by using tools such as iperf3 or bbcp. Ignore theoretical maximums such as claims made by equipment manufacturers.
  3. Estimate compression savings: Evaluate data compressibility by using Zstandard on actual data. Consider worst-case ratios, especially for already compressed formats, for example, video, database dumps, and others.

Decision criteria after evaluating your environment

After gathering traffic, bandwidth, and compression measurements from your environment, you can use the following criteria to assess whether you need DRBD Proxy:

  • If peak write rate ≤ sustainable WAN bandwidth → DRBD is sufficient.
  • If average write rate ≤ sustainable WAN bandwidth → DRBD Proxy without compression is sufficient.
  • If peak write rate ÷ compression ratio ≤ WAN bandwidth → DRBD Proxy with compression is effective.

If none of the above conditions are true, use asynchronous backups, such as thin-provisioned volume snapshots shipped off-site on a schedule.

DRBD Proxy deployment models

If you determine that you need DRBD Proxy, there are two deployment models. The following table describes these models:

Deployment Model Advantages Disadvantages Use Case
Per-node Proxy
(one instance on each DRBD node)		 Simple installation
No extra network hops		 Minor CPU and memory impact per node Default recommendation for most clusters
Dedicated Proxy Nodes Efficient for centralized compression or encryption
Can be secured in DMZ		 Requires additional infrastructure
Single point of failure if not redundant		 Large environments or high-security zones

Guidelines and recommendations for using DRBD Proxy

The following list details some compatibility guidelines and recommendations for using DRBD Proxy.

  • Kernel requirement: DRBD Proxy v4 requires Linux 5.6 or newer (kernel supports io_uring).
  • Compatibility: DRBD Proxy v4 configuration is compatible with v3 configuration files.
  • Buffer size: Use peak_MiBps × burst_duration × 2 as a conservative estimate.
  • CPU usage: Zstandard compression is CPU-intensive. Estimate 0.5 cores per 200–300 MiB/s.
  • Encryption: Using DRBD kTLS encryption is recommended. Enabling this encryption secures your replicated data in transit and has minimal CPU impact when used with modern ciphers.

Deploying DRBD Proxy deployment models

Here is a general outline of steps for deploying DRBD Proxy:

  1. Collect metrics: Assess application I/O and WAN throughput.
  2. Initial deployment: Install DRBD Proxy on non-critical nodes in buffer-only mode.
  3. Enable encryption: Verify that CPU impact is tolerable when enabling DRBD kTLS encryption.
  4. Enable compression: Assess compression ratio compared with CPU usage.
  5. Simulate failure: Test WAN interruptions and verify smooth recoveries.
  6. Roll out cluster-wide: Scale up deployment, enable monitoring, and stay on top of dashboards, alerts, and other notifications that might show issues with the deployment.

Summary

DRBD Proxy v4 offers several improvements over previous versions, including encryption by using support in DRBD for kTLS and increased queue and compression performance. DRBD Proxy can provide a critical benefit when real-time data replication traffic has to travel over constrained or lossy WAN links.

When determining whether you should use DRBD Proxy, a key principle is: Measure first, deploy second.

Written by YY: 2025-06-16.

Reviewed by MDK, MAT: 2025-06-18