Gluster 性能

Gluster 性能

目前我尝试设置 Gluster 集群,但性能很奇怪,我不确定我是否配置了错误的东西。我使用 4x Hetzner 根服务器,运行 Debian Buster,配备 Intel i7、128GB RAM、两个 NVMe 和一个 HDD。每个系统都有一个单独的 10Gbs 网络接口用于内部通信(所有主机都直接连接到一个机架上的一个交换机)。

当我使用 iperf 测试网络时 - 所有对等点之间的速度约为 9.41 Gbits/秒。

我已经安装了 Debian 默认的 glusterfs-server 包(glusterfs-server_5.5-3_amd64.deb)。

我已经构建了三卷:

  • /mnt/ssd/gfs/gv0 上的 SSD(gv0)
  • /mnt/hdd/gfs/gv1 上的 HDD(gv1)
  • /mnt/ram/gfs/gv2 上的 RAM 磁盘 (gv2)

gluster volume create gv0 replica 2 transport tcp 10.255.255.1:/mnt/ssd/gfs/gv0 10.255.255.2:/mnt/ssd/gfs/gv0 10.255.255.3:/mnt/ssd/gfs/gv0 10.255.255.4:/mnt/ssd/gfs/gv0 force
...

还有一些配置变化 - 所有卷看起来都像这样(gv0,gv1 和 gv2 相同)

# gluster volume info gv0
 
Volume Name: gv0
Type: Distributed-Replicate
Volume ID: 0fd68188-2b74-4050-831d-a590ef0faafd
Status: Started
Snapshot Count: 0
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.255.255.1:/mnt/ssd/gfs/gv0
Brick2: 10.255.255.2:/mnt/ssd/gfs/gv0
Brick3: 10.255.255.3:/mnt/ssd/gfs/gv0
Brick4: 10.255.255.4:/mnt/ssd/gfs/gv0
Options Reconfigured:
performance.flush-behind: on
performance.cache-max-file-size: 512MB
performance.client-io-threads: off
nfs.disable: on
transport.address-family: inet

后来在网上找到了一些优化,但是性能提升不大(当然是单线程性能测试)。

# gluster volume info gv0
 
Volume Name: gv0
Type: Distributed-Replicate
Volume ID: 0fd68188-2b74-4050-831d-a590ef0faafd
Status: Started
Snapshot Count: 0
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.255.255.1:/mnt/ssd/gfs/gv0
Brick2: 10.255.255.2:/mnt/ssd/gfs/gv0
Brick3: 10.255.255.3:/mnt/ssd/gfs/gv0
Brick4: 10.255.255.4:/mnt/ssd/gfs/gv0
Options Reconfigured:
performance.write-behind-window-size: 1MB
cluster.readdir-optimize: on
server.event-threads: 4
client.event-threads: 4
cluster.lookup-optimize: on
performance.readdir-ahead: on
performance.io-thread-count: 16
performance.io-cache: on
performance.flush-behind: on
performance.cache-max-file-size: 512MB
performance.client-io-threads: on
nfs.disable: on
transport.address-family: inet

我也尝试过使用和不使用巨型帧。但也没有区别

# ip a s
...
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether 6c:b3:11:07:f1:18 brd ff:ff:ff:ff:ff:ff
    inet 10.255.255.2/24 brd 10.255.255.255 scope global enp3s0
       valid_lft forever preferred_lft forever

所有三个卷都直接安装在其中一个对等点上

10.255.255.1:gv0 /mnt/gv0 glusterfs defaults 0 0
10.255.255.1:gv1 /mnt/gv1 glusterfs defaults 0 0
10.255.255.1:gv2 /mnt/gv3 glusterfs defaults 0 0

然后,我在单独的 RAM 磁盘中创建了一些测试数据。我编写了一个脚本,该dd if=/dev/urandom脚本使用 for 循环生成许多文件。我首先生成文件,因为/dev/urandom当我写入 RAM 磁盘时,速度似乎在 45Mb/s 左右“结束”。

----- generate files 10240 x 100K
----- generate files 5120 x 1000K
----- generate files 1024 x 10000K
sum: 16000 MB on /mnt/ram1/

现在开始转账。我刚刚打电话给cp -r /mnt/ram1/* /mnt/gv0/等,让他们写信并cp -r /mnt/gv0/* /mnt/ram1/计算秒数。这看起来很糟糕。

                    read    write
ram <-> ram           4s       4s
ram <-> ssd           4s       7s
ram <-> hdd           4s       7s
ram <-> gv0 (ssd)   162s     145s
ram <-> gv1 (hdd)   164s     165s
ram <-> gv2 (ram)   158s     133s

因此,与 gluster 集群相比,本地磁盘的读写性能大约快 40 倍。这不可能。

我错过了什么?

相关内容