GreatSQL 開源資料庫 & NVIDIA InfiniBand存算分離池化方案：實現高性能分散式部署

NVIDIA InfiniBand是一種被廣泛使用的網路互聯技術，基於IBTA(InfiniBand Trade Association)而定義的高帶寬、低延時、低CPU占用率、大規模易擴展的通信技術，是世界領先的超級電腦的互連首選，為高性能計算、人工智慧、雲計算、存儲等眾多數據密集型應用提供了強 ...

NVIDIA InfiniBand是一種被廣泛使用的網路互聯技術，基於IBTA(InfiniBand Trade Association)而定義的高帶寬、低延時、低CPU占用率、大規模易擴展的通信技術，是世界領先的超級電腦的互連首選，為高性能計算、人工智慧、雲計算、存儲等眾多數據密集型應用提供了強大的網路性能支撐。通過高速的InfiniBand技術，將業務負載由單機運行轉化為基於多機協作的高性能計算集群，並使高性能集群的性能得以進一步釋放與優化。

GreatSQL是由萬里資料庫維護的國內自主MySQL分支版本，專註於提升MGR可靠性及性能，支持InnoDB並行查詢特性，適用於金融級應用。

此次通過對比測試基於InfiniBand 的 NVMe SSD池化方案及本地NVMe SSD的傳統方案的性能表現，評估使用基於InfiniBand的存算分離架構對分散式資料庫性能的提升程度及擴展性。

經過雙方合作，通過大量數據分析，可以看出基於InfiniBand池化方案的存算分離架構的性能更優、穩定性更強，為GreatSQL實現更高性能的分散式部署提供了有力的技術平臺支撐。

1、NVIDIA InfiniBand 池化方案介紹

file

分散式資料庫集群由兩部分組成：

計算節點是無SSD盤的裸金屬伺服器，運行MySQL資料庫服務程式；
存儲節點提供NVMe SSD資源池，通過軟體聚合方式提供高性能Lun實現對於資料庫的數據的存儲服務；

兩部分伺服器通過Quantum 平臺的InfiniBand網路實現對計算節點和存儲節點的無損連接，結合NVMe-oF（NVMe over Fabric）高效的數據存儲傳輸協議，將存儲節點的Lun掛載到計算節點，實現結算節點本地高性能的數據存儲能力。

測試環境

為了可以公平對比兩種方案的優劣，兩次測試均採用同一臺計算伺服器進行測試，不同的是，本地方案存儲由本地的PCIe4.0 NVMe SSD承載，InfiniBand 池化方案由100Gbps速率的HDR100網卡接入，通過相同型號的NVMe SSD組成的全閃伺服器藉助NVMe-oF提供高性能虛擬Lun完成數據訪問。

2.1 存儲設備

本次測試主要採取兩種存儲方案：

InfiniBand + NVMe SSD設備
本機掛NVMe SSD設備

$ nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
# InfiniBand + NVMe SSD設備
/dev/nvme0n1          MNC12                Mellanox BlueField NVMe SNAP Controller  1           1.10  TB /   1.10  TB    512   B +  0 B   1.0

# 本機掛載的兩個NVMe SSD設備
/dev/nvme2n1          S5L9NE0NA00144       SAMSUNG MZWLJ7T6HALA-0007C               1           7.68  TB /   7.68  TB    512   B +  0 B   EPK99J5Q
/dev/nvme3n1          S5L9NE0NA00091       SAMSUNG MZWLJ7T6HALA-0007C

2.2 CPU&記憶體

記憶體：512GB
CPU，最多128核

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              128
On-line CPU(s) list: 0-127
Thread(s) per core:  2
Core(s) per socket:  32
Socket(s):           2
NUMA node(s):        1
Vendor ID:           AuthenticAMD
BIOS Vendor ID:      Advanced Micro Devices, Inc.
CPU family:          23
Model:               49
Model name:          AMD EPYC 7542 32-Core Processor
BIOS Model name:     AMD EPYC 7542 32-Core Processor
Stepping:            0
CPU MHz:             3381.667
CPU max MHz:         2900.0000
CPU min MHz:         1500.0000
BogoMIPS:            5799.52
Virtualization:      AMD-V
L1d cache:           32K
L1i cache:           32K
L2 cache:            512K
L3 cache:            16384K
NUMA node0 CPU(s):   0-127
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca

2.3 操作系統

OS：CentOS 8
內核：Linux g4 5.4.90-1.el8.x86_64 #1 SMP Fri Mar 11 10:11:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linu

文件系統

$ mount | grep xfs
LABEL=/nvme0 /nvme0    xfs     defaults,noatime,nodiratime,inode64 0 0
LABEL=/nvme2 /nvme2    xfs     defaults,noatime,nodiratime,inode64 0 0
LABEL=/nvme3 /nvme3    xfs     defaults,noatime,nodiratime,inode64 0 0

$ df -hT
/dev/nvme0n1   xfs       1.0T  247G  778G  25% /nvme0
/dev/nvme2n1   xfs       7.0T  1.1T  6.0T  15% /nvme2
/dev/nvme3n1   xfs       7.0T  245G  6.8T   4% /nvme3

2.4 壓測參數&指標

壓測工具：sysbench
- 模式：oltp_read_write。
- 每輪壓測時長：900秒。
- 每輪壓測休眠間隔：180秒。
共64個表。
每個表12500000條記錄。
整個測試庫大小約186G。
採用InnoDB引擎。
併發線程數變化：8、16、32、64、128。
ibp（innodb buffer pool）變化：47G、93G、140G、186G（約為物理數據的25%、50%、75%、100%）。
主要參數選項

sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 32M
innodb_log_file_size = 2G
innodb_log_files_in_group = 3
innodb_doublewrite_files = 2
innodb_io_capacity = 400000
innodb_io_capacity_max = 800000
innodb_flush_method = O_DIRECT
innodb_thread_concurrency = 0

sysbench測試命令模板：

$ sysbench oltp_read_write.lua \
  --tables=64 \
  --table_size=12500000\
  --report-interval=1 \
  --threads=128 \
  --rand-type=uniform \
  --db-ps-mode=disable \
  --mysql-ignore-errors=all \
  --time=900 run

3.性能表現&總結

3.1測試總結

結論先行，整體測試情況如下：

當ibp不足以覆蓋全部物理數據時：

1）GreatSQL 8.x性能遠高於GreatSQL 5.7。

2）併發線程數越高，IB+NVMe SSD vs 本地NVMe SSD 的差距越小。

3） ibp越大，GreatSQL 5.7和8.0性能越接近。
當ibp基本可以覆蓋全部物理數據時：

1） GreatSQL 5.7的性能整體比GreatSQL 8.0略好。
總的測試下來看，IB NVMe SSD 相比本地NVMe SSD的性能更好，也更穩定一些。
嘗試對比測試了組提交（binlog group commit），在本案中對性能影響很小，這裡不再贅述。
嘗試對比設置 innodb_thread_concurrency = 64|128，發現加上後，在ibp足夠大，且併發也打滿128線程後，性能更穩定些，波動沒那麼大了，且最終整體性能也能提升約8% ~ 10%（不過也要考慮到，真實生產環境中，很少會跑滿這麼大壓力）。
總的來說，當物理記憶體不足以覆蓋業務數據時（生成環境中這種情況很常見），如果單靠增加物理記憶體以提升資料庫性能可能從性價比角度看並不划算，不如換個思路，提升本地物理I/O設備的性能，畢竟現在NVMe SSD的性能可以跑到很高。