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

[craftx]

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

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

mysql 只是随便举个例子。

[ElmerZhang]

@SKYNE 去年用了一段时间 longhorn ，遇到最麻烦的问题：万一服务异常服务器 CPU 跑满，该节点上所有 longhorn 盘都会 io error ，虽然 redeploy 可恢复，但是要一个个手动操作，很麻烦。
现在已经把 longhorn 都下掉了

[Mirana]

存算分离是存储和计算是独立的两个集群 这样部署应该叫超融合

[SKYNE]

@ElmerZhang 我们的应用通过 helm 部署，默认都有 limit 限制，存储节点也尽量只作为存储，目前还没遇到过问题

[dcoder]

@craftx

要把一个网盘当本地(persistent)硬盘用, 需要:
1. 找到 cloud vendor 提供的相应水平的网盘.
2. mount 上之后, 自己做 performance 测试, 保证你 db 跑在上面真的行.

另外, docker/k8s 其实一直是个残废, 比如搞 stateful 的东西就巨难...
真的要用 docker/k8s, 得接受这个事实, 劲量只当做 stateless computing cluster 来用.

[litguy]

mysql 只需要一个分布式块存储就行了，不需要分布式文件系统
也可以用 ZFS 作一个 HA 方案，block 通过 iscsi 给 mysql 用
性能还是 OK 的
你可以想象每个 ZFS 节点一对 NVME 作 RAID1 ，两个 ZFS 通过 ZIL 层作强一致

[julyclyde]

@litguy mysql 明说了需要“块”存储吗？
还是随便一个存储就可以？


@dcoder 说的对，尽量只用 stateless 。但是近几年有个趋势就是新入行的人根本不懂除了 docker 之外的世界

[litguy]

@julyclyde 之所以说块存储，是因为分布式块的性能比分布式文件系统高，你的场景中，只需要一个卷挂载点，mysql 迁移到新的 docker 后，只要这个 docker 挂载这个卷，mysql 起来就可以继续读写，你并不是几个 docker 中的应用要同时读写一个文件

[trzzzz]

@ysjiang4869 可以试一下 JuiceFS