![b46e30a7a0702c6f8060a07c9af3e2b7.png](https://i-blog.csdnimg.cn/blog_migrate/51477042df18778e550dff483ca296af.jpeg)
前言: 在我司应用服务、中间件、数据库服务等的监控数据存储在时序数据库influxdb中。
目前influxdb实例占用资源情况:
- 8台物理机 48c96G
- 存储空间 307G
- 高峰写入ops 22w/s
- 内存总占用 139G
- series 411w
写入量随着业务量的增长持续增长,influxdb的扩展起来比较困难。计划装入容器,并使用分布式存储ceph实现存储计算分离,实现计算层的极致扩展与高可用。
容器化探索第一步——本地存储
influxdb配置文件通过volume 挂载configMap映射到POD容器中的配置文件目录
![80d135363cb8ba7c02aca49757d2f0d9.png](https://i-blog.csdnimg.cn/blog_migrate/ef1f75cfbec4c4f6b3390c5f971e269a.jpeg)
influxdb需要持久化数据属于有状态的服务 ,所以pod类型选择了StatefulSet。StatefulSet特点是:拥有稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现。
首先通过在k8s中创建PV映射本地磁盘目录,最终挂载到容器中的influxdb的数据目录,这样不管 Pod 调度到哪个节点,都能挂载同一个卷,从而很容易读取或存储持久化数据。
![d0bf7525f0581bb7bf0b085c65adf9c6.png](https://i-blog.csdnimg.cn/blog_migrate/678b42daa2fbee070b1ca29852bc315d.jpeg)
测试写入10w/s
./influx-stress insert -r 60s --strict --pps 100000 --host http://XXXXXX:XXXXX
Write Throughput: 98524
Points Written: 6010000
测试写入60w/s
[root@db6.dwb.dgt bin]# ./influx-stress insert -r 60s --strict --pps 600000 --host http://XXXXXX:XXXX
Write Throughput: 593223
Points Written: 36200000
测试写入60w/s持续2个小时压测
[root@db6.dwb.dgt bin]# ./influx-stress insert -r 7200s --strict --pps 600000 --host http://XXXXX:XXXX
![a920f4857c3a52f24e429c9ea9589678.png](https://i-blog.csdnimg.cn/blog_migrate/d706142ded482230851831a7de1aefea.png)
总结:可以看出容器中挂载本地存储后性能几乎无损与物理机相当,不过使用本地存储其实还发挥不出来容器化的优势。数据库做容器化主要还是为了提高资源的利用率,实现弹性调度。那么数据库要实现弹性调度首先要解决数据库存储计算分离,然后让计算层在容器中实现弹性调度,这样才能发挥容器的优势。在传统数据库如MySQL innodb中存在很严重的写放大问题,如果在存储层再加入网络IO,那么对于大多数应用场景就不太能接受了。不过对于influxdb这种对底层存储引擎采用类似LSM结构的TSM引擎来说问题就小了很多,写入仅有WAL日志开销,对写入很友好。
可以使用 K8s 结合 分布式存储Ceph 完成真正的存储计算分离。
我们知道k8s中PV的访问模式有3种:
- ReadWriteOnce - 卷可以由单个节点以读写方式挂载
- ReadOnlyMany - 卷可以由许多节点以只读方式挂载
- ReadWriteMany - 卷可以由许多节点以读写方式挂载
- 要实现我们的目前需要第三种模式ReadWriteMany
k8s中CephFS支持以上3种,而Ceph RDB只支持前两种,不支持ReadWriteMany 。
所以下一步来测试influxdb在分布式存储CephFS中的性能。
容器化探索第二步——分布式存储
这里采用k8s部署rook+ceph存储系统
![95daa5fe051b9f6b8dec908e3b94dd39.png](https://i-blog.csdnimg.cn/blog_migrate/5c36ef88fb382aa10b147e3bc931cc6f.jpeg)
启动influxdb pod并通过PV、 PVC挂载cephfs
压测对比
![74fba57253c023e27cb04588d38e906a.png](https://i-blog.csdnimg.cn/blog_migrate/ed3525ebf86f1060e4be7ed1cc041edd.jpeg)
![5af1e6cc36c00ea2f5a4420e61b5ebb8.png](https://i-blog.csdnimg.cn/blog_migrate/a80e515982585eecf4d300e18dcfd26b.jpeg)
![6ce387f6533493ad5f978ac58777b471.png](https://i-blog.csdnimg.cn/blog_migrate/fba97b15971ec977ae8b60aef9593b28.jpeg)
总结:存储计算分离后相较于本地存储写入性能损失接近一半,而且伴有写超时。
容器化探索第三步——计算节点调度与故障转移
存储计算分离后将有状态的数据下沉到存储层,调度pod只要满足计算资源要求的 Node上,这样就做到了计算节点随pod漂移。influxdb实例随pod启动时,只需cephfs挂载 mapping 的 volume 即可。显著提高数据库实例的部署密度和计算资源利用率,还能实现计算节点的故障转移与扩容。
不过这里还会存在以下问题:
1、k8s中PV以ReadWriteMany模式挂载到多个节点,那么在每个节点上看到的数据是不是完全一致?
influx0启动并写入数据
![3c14e83623fb5f509f0ee8621119c086.png](https://i-blog.csdnimg.cn/blog_migrate/687d83828f39437057113c4088915f52.jpeg)
influx1启动并挂载数据
![73556c43729a808445db1d2bbda511c9.png](https://i-blog.csdnimg.cn/blog_migrate/f04f2299ee39c58e7f5c66402d5b5d35.jpeg)
influx0继续写入数据
![410d2bb51462a919ea31f257f38abd7e.png](https://i-blog.csdnimg.cn/blog_migrate/76d6bd137e7be0e5e744e7303ce4cd77.jpeg)
![b96b4b99c513fb9a446871f90be2bf80.png](https://i-blog.csdnimg.cn/blog_migrate/f3979b3af9f3b698a5078b67d807d626.jpeg)
以挂载时间点为界,只能看到挂载前已经存在的数据,看不到挂载后其他节点写入的数据。
2、如果多个节点都写入相同的数据会出现什么情况?
多节点写入相同的数据按写入先后顺序,最终后写入的数据覆盖先写入的数据。(需要避免多写)
参考:
记录一次我做的influxDB性能测试 - 测试开发笔记www.yinyubo.cn![86d6067708003d2d85ca9138686f53ab.png](https://i-blog.csdnimg.cn/blog_migrate/1d34f02ac33b1ba114656db6333c89ee.jpeg)
![d161cb5780b09782fed6385c60bfb941.png](https://i-blog.csdnimg.cn/blog_migrate/a3c00be62823e17bdc0a4e5b7051d110.jpeg)
![845f7555ee66c3a2573c01e83a2e37c4.png](https://i-blog.csdnimg.cn/blog_migrate/89453646b3f76eefb9c3e4594a715f30.jpeg)