分布式文件系统是否可以解决 docker 集群服务数据持久化的问题？

[craftx]

比如，mysql ，需要把数据持久化到本地文件。
但如果用 docker 集群跑 mysql ，默认情况下，实例是会被调度到别的节点的，而持久化的文件固定在节点本地。
docker swarm 的解决方案是给某个节点加 label ，指定 mysql 的部署节点 label 要求，mysql 就不会到处跑了。
不知道 k8s 的解决方案是什么。

但如果，使用 MinIO 或者 SeaweedFS 之类的解决方案，把每个节点的磁盘空间，组成一个分布式文件系统，让 docker 集群上的服务，通过 POSIX API 或者 s3 兼容接口去访问这个分布式文件系统，就像访问当前节点的文件系统。
这么还能充分利用各个节点的闲置磁盘空间。
当然，还要能接受分布式文件系统带来的性能损耗。

mysql 只是随便举个例子。

[piku]

有没有一种可能，他们可以共用同一个 iSCSI 之类的存储

[huigeer]

mysql 这种不能随便举例子，它属于有状态实例，不合适。
容器化的存储方案有多种，本地，分布式，按自己的实际需求来

[star7th]

如果只是短期的日志，我会保存到节点所在硬盘。
对于长期储存，我会用服务器直接起一个 NFS 服务给各大容器公用。
对于数据库存储，我用服务器搭建，不用容器

[SKYNE]

可以看一下 rancher ，rancher 本身是一个 k8s 管理平台

[realrojeralone]

1 楼正解，解决方案是块存储，比如 Ceph

[SKYNE]

不好意思，误操作回复了，
rancher 可以配合使用分布式储存 longhorn ，
你可以划定某些节点作为存储节点，
将 longhorn 作为储存类，动态分配给你的应用使用，
目前使用下来挺稳定的，kafka 、MQ 、MySQL 有状态应用也跑在上面
遇到的问题，节点间磁盘使用率有点不均衡，这取决于分配到磁盘上的 pvc 的大小

[mengpp]

分布式存储带来的性能损失会比想象中影响更大,尝试过团队开发环境使用 k8s+gluster 部署 mysql 使用,后面因为使用一段时间后,随着数据的增长,性能比较差,又回归到本地存储了

[craftx]

@huigeer
@mengpp
en
mysql 这个例子的确不太合适，只是立马想到了 mysql ，大家也肯定都知道 mysql

[craftx]

@star7th 眼下要解决的问题，就是存储日志。
如果日志保存到节点所在的磁盘
怎么做到聚合查询呢？
暂时准备 loki 日志方案

[craftx]

@mengpp 目前首先要解决的问题是存储日志
如果分布式文件性能损失太大，分布式数据库是不是同样不可接受？

[youngce]

@craftx 日志、分布式、性能、数据库——>elasticsearch ？

[firemiles]

@craftx 搞个 agent 采集日志不挺好的

[julyclyde]

mysql 也可以吧。挂 volume 进去就行了

[mengpp]

@craftx 还是看场景吧,分布式文档数据库对于明显的冷热数据场景挺擅长的,比如 ES;
然后分布式关系型数据库发力的应该是数据分类算法和数据存储算法吧(猜测,没详细了解过),所以能降低性能损耗带来的影响,尝试过 TIDB 和 OB,小表性能体验一般,大表还蛮好的;
另外我尝试的场景中,性能损失大部分也是因为分布式存储多副本的原因,不止网络和 IO

[ysjiang4869]

日志的方案，应该日志转发到统一的存储中，这个统一的存储可以是数据库、另外的一台日志机器、消息队列等

MySQL 这种数据库，通常会选择绑定节点，docker 和 k8s 都有 label 这样的绑定，通过主从保证高可用吧。

分布式文件系统 100%影响性能，ceph 不是一般小公司能搞定的，里面的坑坑重度用起来问题挺多的，读写速度也不快。

[billlee]

存日志的场景，应该是直接把日志通过网络打到日志服务上。

[onehao28]

这不就是计算+存储分离的方案吗？ 现在很多数据库都在做类似的，华为的 redis 还有腾讯的 CynosDB 也就是 tdsql-c 就是基于这个架构，用了底层块存储共享能力。

[salmon5]

就是计算和存储分离，云厂商搞了 2-3 年了

[salmon5]

好几年了

[craftx]

@billlee 这个直接，是指不通过 agent ，服务直接把日志发送到日志服务？