10GigE上的DRBD糟糕的同步性能


15

我已经设置了一对具有RAID阵列(8核,16GB RAM,12x2 TB RAID6),3个10GigE接口的相同服务器,以承载一些高可用性服务。

该系统当前正在运行Debian 7.9 Wheezy oldstable(因为在8.x稳定版或测试中无法使用corosync / pacemaker)。

  • 本地磁盘性能约为900 MB / s写入,1600 MB / s读取。
  • 机器之间的网络吞吐量超过700MB / s。
  • 通过iSCSI,每台计算机可以超过700 MB / s的速度写入对方的存储。

但是,无论我以哪种方式配置DRBD,吞吐量都被限制为100MB / s。它确实看起来像是一些硬编码的限制。通过调整设置,我可以可靠地降低性能,但是它永远不会超过1Gbit(一次连续几秒钟达到122MB / s)。我真的很喜欢这个。

  • 普通香草核3.18.24 amd64
  • drbd 8.9.2〜rc1-1〜bpo70 + 1

配置分为两个文件global-common.conf

global {
        usage-count no;
}

common {
        handlers {
        }

        startup {
        }

        disk {
                on-io-error             detach;
         #       no-disk-flushes ;
        }
        net {
                max-epoch-size          8192;
                max-buffers             8192;
                sndbuf-size             2097152;
        }
        syncer {
                rate                    4194304k;
                al-extents              6433;
        }
}

cluster.res

resource rd0 {
        protocol C;
        on cl1 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.1:7788;
                meta-disk internal;
        }

        on cl2 {
                device /dev/drbd0;
                disk /dev/sda4;
                address 192.168.42.2:7788;
                meta-disk internal;
        }
}

cat /proc/drbd站上的输出:

version: 8.4.5 (api:1/proto:86-101)
srcversion: EDE19BAA3D4D4A0BEFD8CDE 
 0: cs:SyncTarget ro:Secondary/Secondary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:4462592 dw:4462592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:16489499884
        [>....................] sync'ed:  0.1% (16103024/16107384)M
        finish: 49:20:03 speed: 92,828 (92,968) want: 102,400 K/sec

来自vmstat 2主服务器的输出(两台机器几乎都处于空闲状态):

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 14952768 108712 446108    0    0   213   254   16    9  0  0 100  0
 0  0      0 14952484 108712 446136    0    0     0     4 10063 1361  0  0 99  0
 0  0      0 14952608 108712 446136    0    0     0     4 10057 1356  0  0 99  0
 0  0      0 14952608 108720 446128    0    0     0    10 10063 1352  0  1 99  0
 0  0      0 14951616 108720 446136    0    0     0     6 10175 1417  0  1 99  0
 0  0      0 14951748 108720 446136    0    0     0     4 10172 1426  0  1 99  0

iperf两台服务器之间的输出:

------------------------------------------------------------
Client connecting to cl2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 192.168.42.1 port 47900 connected with 192.168.42.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  6.87 GBytes  5.90 Gbits/sec

显然,初始同步应该有点慢,但不会慢一些……此外,它实际上对任何限制同步速率的尝试都没有反应drbdadm disk-options --resync-rate=800M all


1
您是否尝试过异步构建它,然后停止它并重新构建它以重新同步?
Xavier Nicollet

Answers:


11

在较新版本的DRBD(8.3.9及更高版本)中,有一个动态重新同步控制器需要调整。在较旧的DRBD版本中,设置syncer {rate;}足够了。现在,它已被用作动态重新同步速度的一个建议的起点。

动态同步控制器已通过DRBD配置的磁盘部分中的“ c-settings”进行了调整($ man drbd.conf有关这些设置的详细信息,请参见)。

在这些节点之间使用10Gbe的情况下,并假设由于使用了协议C而导致低延迟,因此以下配置应该可以使操作更快:

资源rd0 {
        协议C;
        磁盘{
                c-fill-target 10M;
                c-max-rate 700M;
                提前计划c; 7;
                c-min-rate 4M;
        }
        在cl1 {
                设备/ dev / drbd0;
                磁盘/ dev / sda4;
                地址192.168.42.1:7788;
                内部元磁盘;
        }

        在cl2 {
                设备/ dev / drbd0;
                磁盘/ dev / sda4;
                地址192.168.42.2:7788;
                内部元磁盘;
        }
}

如果您仍然不满意,请尝试max-buffers调高至12k。如果您仍然不满意,可以尝试c-fill-target以2M的增量递增。


实际上,使用此配置,性能会下降到3 MB / s。我正在尝试使用这些设置,但前景很糟糕。
wazoox 2015年

到目前为止,通过将c-plan-a设置为零来禁用它,并增加max-epoch-size和max-buffers似乎可以解决问题。
wazoox 2015年

2
如果将最大缓冲区增加到20k,将c-fill-target增加到20M会发生什么?我相信慢慢增加这两个值最终将为您提供所需的结果。
Matt Kereczman 2015年

那好多了!它不会使链接饱和(专用且虽然可以填充),但我已经达到了400MB / s。我正在使用这些设置...
wazoox 2015年

1
将最大缓冲区从250增加到2500对我而言是昼夜不同的(在我的非关键性能设置中)
davidgo

7

其他人建议我使用以下设置:

        disk {
                on-io-error             detach;
                c-plan-ahead 0;
        }
        net {
                max-epoch-size          20000;
                max-buffers             131072;
        }

而且性能非常好。

编辑: 根据@Matt Kereczman和其他建议,我终于更改为:

disk {
        on-io-error             detach;
        no-disk-flushes ;
        no-disk-barrier;
        c-plan-ahead 0;
        c-fill-target 24M;
        c-min-rate 80M;
        c-max-rate 720M;
} 
net {
        # max-epoch-size          20000;
        max-buffers             36k;
        sndbuf-size            1024k ;
        rcvbuf-size            2048k;
}

重新同步速度很高:

cat /proc/drbd
version: 8.4.5 (api:1/proto:86-101)
srcversion: EDE19BAA3D4D4A0BEFD8CDE
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---n-
    ns:133246146 nr:0 dw:2087494 dr:131187797 al:530 bm:0 lo:0 pe:5 ua:106 ap:0 ep:1 wo:d oos:4602377004
        [>....................] sync'ed:  2.8% (4494508/4622592)M
        finish: 1:52:27 speed: 682,064 (646,096) K/sec

在使用以下设置进行重新同步期间,写入速度非常出色(本地写入速度的80%,全线速度):

# dd if=/dev/zero of=./testdd bs=1M count=20k
20480+0 enregistrements lus
20480+0 enregistrements écrits
21474836480 octets (21 GB) copiés, 29,3731 s, 731 MB/s

读取速度还可以:

# dd if=testdd bs=1M count=20k of=/dev/null
20480+0 enregistrements lus
20480+0 enregistrements écrits
21474836480 octets (21 GB) copiés, 29,4538 s, 729 MB/s

以后编辑:

完全重新同步后,性能非常好(线速写入,本地速度读取)。重新同步很快(5/6小时),并且不会对性能造成太大的影响(线速读取,线速写入)。我一定会保持c-plan-ahead为零。对于非零值,重新同步时间太长。


将最大缓冲区增加到131K并不是解决问题的最优雅方法。您实际上是在给DRBD 512MiB系统缓冲区供其重新同步使用,这是很多缓冲区空间。我已经看到,最大缓冲区大于80k会发生这种情况。我强烈建议调整重新同步控制器的设置,同时以最小的增量增加最大缓冲区,直到您满意为止。
Matt Kereczman 2015年

@MattKereczman我将更改设置,但是我想在使用生产设置之前尽可能快地拥有一个最佳的(已同步)群集。...默认设置意味着同步至少需要花费几天甚至更长的时间。数周之久,这简直是无法接受的。所需的生产吞吐量为500MB / s。
wazoox

4

提前c-plan必须设置一个正值才能启用动态同步速率控制器。磁碟 c-plan-ahead 15; // 5 * RTT / 0.1s unit,in my case is 15 c-fill-target 24; c-max-rate 720M;

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.