현재 Gluster 클러스터를 설정하려고 하는데 성능이 이상하고 뭔가 잘못 구성했는지 잘 모르겠습니다. 저는 Intel i7, 128GB RAM, 2개의 NVMe 및 1개의 HDD와 함께 Debian Buster를 실행하는 4x Hetzner 루트 서버를 사용하고 있습니다. 모든 시스템에는 내부 통신을 위한 별도의 10Gbs 네트워크 인터페이스가 있습니다(모든 호스트는 하나의 랙에 있는 하나의 스위치에 직접 연결됨).
iperf로 네트워크를 테스트했을 때 모든 피어 사이에 약 9.41Gbits/sec가 있었습니다.
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램 디스크에 쓸 때 약 45Mb/s에서 "종료"되는 것 같기 때문에 먼저 파일을 생성했습니다 .
----- generate files 10240 x 100K
----- generate files 5120 x 1000K
----- generate files 1024 x 10000K
sum: 16000 MB on /mnt/ram1/
이제 전송이 이루어집니다. 방금 etc.에 전화해서 초를 쓰고 계산했습니다 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배 더 빠릅니다. 그럴 리가 없어.
나는 무엇을 그리워합니까?