目前我嘗試設定一個 Gluster 集群，但性能很奇怪，我不確定我是否配置錯誤。我使用 4 台 Hetzner 根伺服器，運行 Debian Buster，配備 Intel i7、128GB RAM、兩個 NVMe 和一個 HDD。每個系統都有一個單獨的 10Gbs 網路介面用於內部通訊（所有主機都直接連接到一個機架上的一台交換器）。
當我使用 iperf 測試網路時，所有對等點之間的速度約為 9.41 Gbits/sec。
我已經安裝了 Debian 預設 glusterfs-server 軟體包 (glusterfs-server_5.5-3_amd64.deb)。
我已經製作了三卷：
- /mnt/ssd/gfs/gv0 上的 SSD (gv0)
- HDD (gv1) 位於 /mnt/hdd/gfs/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 cluster的讀寫效能快了40倍左右。那不可能。
我想念什麼？