現在、Gluster クラスターをセットアップしようとしていますが、パフォーマンスがおかしく、何か間違った設定をしたかどうかわかりません。Intel i7、128GB RAM、2 つの NVMe、1 つの HDD を搭載した Debian Buster を実行する 4x Hetzner ルート サーバーを使用しています。各システムには、内部通信用に個別の 10Gbs ネットワーク インターフェイスがあります (すべてのホストは、1 つのラックの 1 つのスイッチに直接接続されています)。
iperf を使用してネットワークをテストすると、すべてのピア間の速度は約 9.41 Gbits/秒になります。
Debian のデフォルトの glusterfs-server パッケージ (glusterfs-server_5.5-3_amd64.deb) をインストールしました。
私は次の3つのボリュームを構築しました:
- /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
3つのボリュームはすべてピアの1つに直接マウントされます
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 ディスクにテスト データをいくつか作成しました。 多くのファイルを生成するスクリプトと for ループを作成しました。 RAM ディスクに書き込むと、約 45Mb/s で「終了」すると思われるdd if=/dev/urandomため、最初にファイルを生成しました。/dev/urandom
----- 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/秒数を数えるために、etc に電話をかけました。そして、それはひどいようです。
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 倍高速になります。そんなことはあり得ません。
何が欠けているのでしょうか?