TiDB 落地 SAS 机器实践
作者: jiaxin 原文来源:https://tidb.net/blog/3e3570d7
背景
目前大环境下,需有效利用现有机器资源来支撑业务应用的数据读写存储;多点现有 TiDB 集群大都是 NVME SSD 高配机器,TiDB 库场景多,其中就有 QPS 低但消耗空间大(逻辑数据量 17T,6 tikv 机器共 22T 磁盘,业务应用对查询延迟不敏感)的某 TiDB 集群(冷热分离类场景,MySQL 热数据 ->TiDB 冷数据),准备把该集群迁移至 IDC 4 台 48C 万兆网卡共 180T RAID10 SAS 机器(每台机器 250G 内存,3*15T data 盘,每 data12 块盘,每块盘 8T)
机器性能测试表现
IDC RAID0、RAID10 SAS 机器 IO 吞吐性能表现:随机读写吞吐差,顺序读写吞吐和 nvme 机器差不多
使用 fio 进行测试,RAID10(镜像 + 分片)机器是现有 SAS 机器测试,RAID0(分片)找运维支持单独格式化了台机器
部署方案
每台机器 250G 内存按使用率 70%,可使用内存 175G;每台机器磁盘共 45T 按使用率 70%,可使用磁盘 31T
内部评估讨论下来使用方案三:3 TiDB 集群 1TiKV 节点 /15T data 盘,部署维护相对简单,不用配置 Placement Rules
TiKV 内存 block_cache_size 需要比理论 70% 内存水位消耗的 block_cache_size 小,TiKV 节点非 block_cache 部分会消耗一定内存(如理论 1TiKV block_cache_size 50GB,实践配置 1TiKV block_cache_size 40GB)
方案一:1 TiDB 大集群 2TiKV 节点 / 15T data 盘
每机器部署 8 个组件(6 tikv+1 tidb+1pd),tikv 三副本,内存限制 25G(block_cache_size=25G),tikv 25G*6 + tidb 25G=175G(70% 内存水位),pd 基本不消耗内存
1 个 TiDB 大集群,每 15T data 盘放 2 TiKV 节点
优点
1 个 tidb 大集群多库部署简单,运维管理方便
1 套大集群能使用空间 180T*70%=126T
同台机器 3 块 RAID10 data 盘最多允许宕 3 块不同盘
限制
单 tikv 空间最大可到 10T(最大 70% 利用率),单 tikv region 多导致 tikv<->pd、tikv region<->tikv region 之前网络心跳压力大,需调大单 region size,限制 region 最大 key 数量,开启 region 静默减少网络压力
需开启 Placement Rules 保证 tikv 相同副本在不同机器上
1 集群多库存在某库大查询影响其它库
方案二:3 TiDB 集群 1TiKV 节点 / 8T data 盘
每机器 6 个 tikv 资源池(每个 tikv 资源池 8T),初始每机器 3 tikv+1 tidb+1pd,tikv 三副本,内存限制 20G(block_cache_size=20G),tikv 20G*6 + tidb 25G=145G < 175G(70% 内存水位)
需要运维把每台机器 3 块 15T RAID10 盘拆分为 6 块 8T RAID1 盘(镜像)
暂部署 3 套集群后续磁盘利用高可扩容资源池中另外 12 个 tikv
优点
不同集群放不同 data 盘,可实现 IO 资源隔离
另外 12 个 buffer tikv 资源池可动态扩容进初始 3 套集群中
限制
需开启 Placement Rules 保证 tikv 相同副本在不同机器上
单 tikv 空间最大可到 5T(最大 70% 利用率),单 tikv region 多导致 tikv<->pd、tikv region<->tikv region 之前网络心跳压力大,需调大单 region size,限制 region 最大 key 数量,开启 region 静默减少网络压力
4 台机器支撑 2 套 TiDB 集群计算节点(每套部署 2 计算节点),第 3 套 TiDB 集群计算节点部署在另外的 2 台 MySQL SAS 上
RAID1 IO 性能有一定下降,同台机器最多允许宕 6 块盘
方案三:3 TiDB 集群 1TiKV 节点 /15T data 盘(使用)
每机器部署 3 个组件(3 tikv+1 tidb+1pd),tikv 三副本,内存限制 50G(block_cache_size=50G),tikv 50G*3 + tidb 25G=175G(70% 内存水位),pd 基本不消耗内存
3 个 TiDB 集群,每 15T data 盘放 1 TiKV 节点
优点
3 个 TiDB 集群多库运维管理方便,不用配置 Placement Rules
不同集群放不同 data 盘,可实现 IO 资源隔离
3 套集群每套集群能使用空间 45T*70%=31T
RAID10 最多允许宕 3 块不同盘
限制
单 tikv 空间最大可到 10T,单 tikv region 多导致 tikv<->pd、tikv region<->tikv region 之前网络心跳压力大,需调大单 region size,限制 region 最大 key 数量,开启 region 静默减少网络压力
4 台机器支撑 2 套 TiDB 集群计算节点(每套部署 2 计算节点),第 3 套 TiDB 集群计算节点部署在另外的 2 台 MySQL SAS 上
相同集群多库存在某库大查询影响其它库
方案四:1 TiDB 大集群 1TiKV 节点 / 4T data 盘
每机器部署 14 个组件(12 tikv+1 tidb+1pd),tikv 三副本(五副本的话还差一台 SAS 机器),内存限制 10G(block_cache_size=10G),tikv 10G*12 + tidb 25G=145G(70% 内存水位),pd 基本不消耗内存
1 个 TiDB 集群,每 4T data 盘放 1 TiKV 节点(需要运维把 3 个 15T 盘拆分为 12 个 4T 盘,12 块 8T 盘组成大 RAID10,再分 12 个 4T 区)
优点
1 个 TiDB 集群多库部署方便,运维管理方便
1 套大集群能使用空间 180T*70%=126T
不需要调整 region size,region 最大 key 数量
限制
单 tikv 空间最大 4T,单 tikv region 少,tikv<->pd、tikv region<->tikv region 之前网络心跳压力小
需开启 Placement Rules 保证 tikv 相同副本在不同机器上
RAID10 分 12 区不同盘性能可能有耦合风险
相同集群多库存在某库大查询影响其它库
SAS TiDB 性能测试表现
根据原默认 96MB region 大小比例调整以下配置减小单 tikv region 数过多时造成的网络心跳压力
sysbench 通用测试
版本:v5.1.2
Region size 96MB 和 Region size 256MB
Sysbench 读写模式、只读模式、只写模式下, region size 256MB 在分别 5,10,20,30,40,80,120 并发线程测试 10 分钟表现均符合预期
96MB 和 256MB 下表 region 相关信息
SSD TiDB&SAS TiDB 业务应用 SQL 测试
SAS TiDB 4 个业务应用库仅有部分历史数据,用来验证 SSD TiDB 和 SAS TiDB SQL 查询延迟
单独备份部分表还原到 SAS 上验证 SQL 性能
扩展区 NVME SSD TiDB 迁移
TiDB 相关组件迁移
4 台 SAS 机器 /data1 盘扩容进现有集群,组成 10 个 TiKV 存储大集群
在其中 3 台 SAS 机器上扩容 3 个 pd 元数据节点,2 台 SAS 机器上扩容 2 个 tidb 计算节点,1 台 SAS 机器上扩容 grafana&prometheus
再把 SSD 机器(pd 节点、tidb 节点、grafana&prometheus)缩容(pd-ct 提前切换 pd leader 至 SAS 机器)只剩 SAS 机器实现扩展区 SSD TiDB 库迁移至 IDC SAS 机器
因为不是单独新部署的一套 TiDB 集群,就没有调整 SAS 机器 TiDB 集群 region size, region keys(参数扩容、缩容方式迁移和原有 SSD TiDB 集群保持了默认一致)
TiDB DNS 解析修改
修改 tidb 域名解析至 SAS 机器 tidb 计算节点
该步骤在 SAS 机器扩容进集群后
DRC 同步修改
自研 DRC 同步工具修改 mysql->tidb 目标 tidb 地址,因目标 tidb 地址是域名,重启 DRC 同步链路后重新解析 tidb 域名至 SAS 机器 tidb 计算节点
该步骤在 SAS 机器扩容进集群后
tiup 中控配置迁移
SAS 机器扩容进现有集群后,高峰期 SAS 机器磁盘性能利用率相比 SSD 机器大
SAS 机器:
SSD 机器:
后续表现
后期 SAS 机器 TiDB 性能表现,P999 延迟有秒级别~ 几十秒,业务应用方也能接受查 TiDB 冷数据延迟时间
Raft store cpu 使用率高峰期超过 110% 左右,raftstore.store-pool-size 参考值 官方参考值为 raftstore.store-pool-size(默认 2) * 85% = 45% 左右,后续增大 store_pool_size 后再持续观察 raft store cpu 使用率
总结
NVME SSD TiDB 集群迁移至 4 台 SAS 机器后节省了 6 tikv 机器 +3 ( tidb+pd ) 机器,单集群共 42T(70% 磁盘水位算)大容量 SAS TiDB 也对低 QPS(业务查询延迟时间不敏感)数据需长期保存业务场景提供有力支撑保障
加强和业务应用方协作,不同业务场景 TiDB 适配不同存储(NVME SSD 机器 or SAS 机器)
单机器多 TiKV 情况下 block_cache_size 内存、磁盘使用上和各组件端口占用方面需提前规划好
单 TiKV 大磁盘情况 region size、region keys 可根据实际测试效果适当增大
专栏 - 百 TB 级 TiDB 集群在线更换 NVME 磁盘优化实践 | TiDB 社区
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/a86f7ac8e6f0349ac10795bb1】。文章转载请联系作者。
评论