seo是什么岗位简称/湖南seo优化首选

前言: 在我司应用服务、中间件、数据库服务等的监控数据存储在时序数据库influxdb中。

目前influxdb实例占用资源情况：

• 8台物理机 48c96G
• 存储空间 307G
• 高峰写入ops 22w/s
• 内存总占用 139G
• series 411w

写入量随着业务量的增长持续增长，influxdb的扩展起来比较困难。计划装入容器，并使用分布式存储ceph实现存储计算分离，实现计算层的极致扩展与高可用。

容器化探索第一步——本地存储

influxdb配置文件通过volume 挂载configMap映射到POD容器中的配置文件目录

influxdb需要持久化数据属于有状态的服务 ，所以pod类型选择了StatefulSet。StatefulSet特点是：拥有稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。

首先通过在k8s中创建PV映射本地磁盘目录，最终挂载到容器中的influxdb的数据目录，这样不管 Pod 调度到哪个节点，都能挂载同一个卷，从而很容易读取或存储持久化数据。

测试写入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

总结：可以看出容器中挂载本地存储后性能几乎无损与物理机相当，不过使用本地存储其实还发挥不出来容器化的优势。数据库做容器化主要还是为了提高资源的利用率，实现弹性调度。那么数据库要实现弹性调度首先要解决数据库存储计算分离，然后让计算层在容器中实现弹性调度，这样才能发挥容器的优势。在传统数据库如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存储系统

启动influxdb pod并通过PV、 PVC挂载cephfs

压测对比

总结:存储计算分离后相较于本地存储写入性能损失接近一半，而且伴有写超时。

容器化探索第三步——计算节点调度与故障转移

存储计算分离后将有状态的数据下沉到存储层，调度pod只要满足计算资源要求的 Node上，这样就做到了计算节点随pod漂移。influxdb实例随pod启动时，只需cephfs挂载 mapping 的 volume 即可。显著提高数据库实例的部署密度和计算资源利用率，还能实现计算节点的故障转移与扩容。

不过这里还会存在以下问题：

1、k8s中PV以ReadWriteMany模式挂载到多个节点，那么在每个节点上看到的数据是不是完全一致？

influx0启动并写入数据

influx1启动并挂载数据

influx0继续写入数据

以挂载时间点为界，只能看到挂载前已经存在的数据，看不到挂载后其他节点写入的数据。

2、如果多个节点都写入相同的数据会出现什么情况？

多节点写入相同的数据按写入先后顺序，最终后写入的数据覆盖先写入的数据。(需要避免多写)

参考：

记录一次我做的influxDB性能测试 - 测试开发笔记​www.yinyubo.cn面向未来的数据库体系架构思考：把数据库装入容器​www.sohu.comPersistent Volumes​kubernetes.iohttps://blog.csdn.net/networken/article/details/85772418​blog.csdn.netShared File System​rook.io