derzeit versuche ich, einen Gluster-Cluster einzurichten, und die Leistung ist seltsam und ich bin mir nicht sicher, ob ich etwas falsch konfiguriert habe. Ich verwende 4x Hetzner-Root-Server mit Debian Buster mit Intel i7, 128 GB RAM, zwei NVMe und einer Festplatte. Jedes System verfügt über eine separate 10-Gbit/s-Netzwerkschnittstelle für die interne Kommunikation (alle Hosts sind direkt mit einem Switch auf einem Rack verbunden).
Wenn ich das Netzwerk mit iperf teste, erhalte ich zwischen allen Peers etwa 9,41 Gbit/s.
Ich habe die Debian-Standard-Glusterfs-Server-Pakete (glusterfs-server_5.5-3_amd64.deb) installiert.
Ich habe drei Bände erstellt mit:
- SSD (gv0) auf /mnt/ssd/gfs/gv0
- Festplatte (gv1) auf /mnt/hdd/gfs/gv1
- RAM-Disk (gv2) auf /mnt/ram/gfs/gv2
Mit
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
...
Und einige Konfigurationsänderungen - alle Volumes sehen so aus (gv0, gv1 und gv2 sind gleich)
# 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
Später habe ich im Netz noch ein paar Optimierungen gefunden. An der Performance ändert sich aber nicht viel (natürlich handelt es sich hier um einen Single-Thread-Performancetest).
# 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
Ich habe es auch mit Jumbo-Frames und ohne probiert. Aber es hat auch keinen Unterschied gemacht
# 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
Alle drei Bände sind direkt auf einem der Peers gemountet
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
Dann habe ich einige Testdaten auf einer separaten RAM-Disk erstellt. Ich habe ein Skript geschrieben, das mit dd if=/dev/urandomeiner For-Schleife viele Dateien generiert. Ich habe die Dateien erst generiert, weil sie /dev/urandombei etwa 45 Mb/s „Ende“ zu sein scheinen, wenn ich auf eine RAM-Disk schreibe.
----- generate files 10240 x 100K
----- generate files 5120 x 1000K
----- generate files 1024 x 10000K
sum: 16000 MB on /mnt/ram1/
Und jetzt kommt die Überweisung. Ich habe gerade angerufen cp -r /mnt/ram1/* /mnt/gv0/usw., geschrieben und cp -r /mnt/gv0/* /mnt/ram1/die Sekunden gezählt. Und das sieht furchtbar aus.
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
Die Leistung beim Lesen und Schreiben mit der lokalen Festplatte ist im Vergleich zum Gluster-Cluster etwa 40-mal schneller. Das kann nicht sein.
Was vermisse ich?