GreatSQL 開源資料庫 & NVIDIA InfiniBand存算分離池化方案：實作高性能分布式部署-有解無憂

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的性能可以跑到很高，