多云 Swarm/k3s 环境如何部署持久存储

[bluedawn]

前提

1. 持久存储试了 glusterfs ，nfs ，s3fs ，sshfs 这些。刚看到 longhorn 的文档暂且还不太了解。
2. 在不同的云服务商购买的裸金属服务器（ vps ）共计 5 台，只有两台在同一地区且互相 ping 少于 1ms 。
3. 有一台 vps 的硬盘存储容量 1t ，希望使用它作为集群主存储空间，但 cpu 性能极弱不可能作为 master 或者 manager 。
4. 目前此集群基于 zerotier 组网。
5. 只是个人用来玩的实验性环境，并非生产环境，希望不要太认真啦。

## 处境

有些容器会使用 sqlite3 作为简易的本地数据库，这就对挂载存储 IOPS 要求提高。
如果在多云环境下许多不同的多云服务商，组成集群的这些 vps 还不在同一个地区那虚拟磁盘的读写速度就更加糟糕了。
这就导致容器使用的 sqlite3 极为缓慢，在外部看起来访问速度几乎不可接受。
可以使用其它数据库弃用 sqlite3 ，但是在一次尝试中发现 postgres 同样对挂载的 volume 的性能要求高，速度差不了多少同样是不可接受的。

## 疑问

1. 像这样的多云环境下如何部署持久化存储才是最佳实践？
2. 观察到用于组网的 zerotier 的首次 ping 延迟会很高，是否它也是一个巨大的影响因素？
3. 希望容器死亡后被重新创建的时候可以继续使用之前的持久化存储内容，但是极有可能不调度在同一个机器上，如果上面两个问题根本无解，也许这种情况更需要的是一个目录同步工具而不是持久化存储？

## 最后

刚开始学习容器编排不久，希望能有大佬可以解惑。
感谢阅读到这里的每一个人，真的非常感谢！！

[bluedawn]

ps: 手机上写 markdown 好像格式错乱了影响阅读真的实在抱歉

[everyx]

在用 juicefs ，简单易用，直接挂载到本地，然后再挂载到容器中，没碰到啥问题

[bluedawn]

@everyx #2 感谢回复，我也尝试了 juicefs 。但是如果用 s3 创建 juicefs 的话，IOPS 完全取决于 s3 供应商的性能，同样还是在用使用 sqlite3 做数据库的容器测试的，cloudflare r2 和 backblaze 都无法完成正常的 sqlite 写入，但是它确实可以作为完美的文件存储空间。还有尝试使用本地磁盘创建的话受限于网络环境也存在一样的问题诶。

[anubu]

倒腾着玩的环境很难讲有什么最佳实践。跨公网环境搞共享存储，IOPS 已经没有意义了。对于 IO 敏感型应用，还是考虑挂载本地卷。可以盘点这些节点的基础设施情况，对使用本地卷的应用进行节点绑定部署。存储备份可以考虑使用同步应用对节点上的存储卷同步和备份。如果实在想要一些调度灵活性，也可以考虑类似 DRDB 的方案，对各个节点的存储卷进行实时同步，不过考虑到公网延迟，实时性应该还是会打折扣。

[momocraft]

为一般磁盘写的东西在网络存储下容易出问题
我宁愿不要直接提供存储, 暴露个数据库服务或者 API 给别的机器用可以了

那台大硬盘机器可以用来放备份

[bluedawn]

@anubu 嗯嗯感谢！确实觉得这样多云跨公网可能绑定节点是更好的选择了，虽然这样又存在单点故障。DRDB 没听说过诶这就去研究一下，感谢大佬指路 w

[bluedawn]

@momocraft 感谢回复，其实同时也在考虑把所有的数据库容器固定在打标签的机器上绑个本地存储，不知道这样做是不是有可行性

[anonydmer]

即使是公有云，数据库也是推荐用单独的服务（如 RDS 之类）；如果实在是要自己在容器集群中部署数据库，推荐使用 LPV 进行本地卷挂载，可以绑定到固定的存储节点，保证 IO 的高性能。 另外友情提示，容器集群中的虚拟化网络层其实对性能影响比较大，因此即使数据库容器服务跑在了固定的节点上，你的应用通过容器网络来访问仍然有不少的性能损失。

[min]

请认真考虑下列问题：
瞎折腾一定要出积极的结果么？

[bluedawn]

@anonydmer #8 感谢指路，虚拟化网络确实损失了好多性能，这就去试试 LPV 。试过几家的 RDS 但是毕竟本身容器不确定会在哪个地区的机器上运行所以虽然能用但是感觉就网络延迟来说不太好用。

[bluedawn]

@min #9 毕竟自己不太会所以来问一问万能的大家啦。不然觉得未尽全力又半途而废，折腾还有什么意义啊。能有解决方案最好但是实在没有也没办法强求。

[kaneg]

既然你提到 NFS ，那就用它了，用那台 1T 存储的服务器搭建 NFS server ，然后在集群用挂载为 PV ，Kubernetes 对 NFS 也是原生支持的。

[anubu]

typo DRDB > DRBD
使用本地卷又考虑节点故障，基本就是使用类似 DRBD 的技术，对节点上的存储目录进行跨节点同步。印象中也有其它类似的同步技术，也可以搜索研究一下。
另外，自己折腾的场景大部分都不是真实的，即真正生产不会有这样的场景，有这样场景的也不会上真正生产业务。其实就是自己练手玩的，大多数都是我想这么做，或者我可以这么做。所以，不必过于追求最佳实践，直接上手试就行。

[perfectlife]

云上建议直接用云盘作为 pv 的后端存储 省事，可靠，比如阿里云，哪怕你自建的 k8s 也支持使用云盘作为 pv 的后端存储

[perfectlife]

建议慎用 nfs 能不用还是不用 nfs 好点 ，有几率出现数据问题，数据出了问题恢复都挺麻烦的，不行考虑用 local pv 什么的 ，反正机器层面云厂商还能都点底

[everyx]

@bluedawn 如果你的 sqlite 数据库还需要多主机共享读 /写，那跨多个云服务商，怎么样速度都上不了啊，如果是 sqlite 数据库只是本机操作，那不怕，有本地缓存，你这类情况持久存储服务只适合做备份用途

[xzysaber]

NFS 跨云，并且大量小文件,例如几千个，会非常慢。最终还是选择放到了本地存储。
NFS 的问题挺多的，还有如果 server 关闭时，client 一定要及时关闭，不然会造成 NFS client 所在的节点系统负载飙升，应该是 CPU 上下文频繁切换导致。我使用的 NFS 4 版本，应该不存在小文件 3 中小文件性能问题。

[xzysaber]

当然在内网的话，NFS 就还好，快很多。
因为跨云，所以看是否可以每个云使用一个内网 NFS 。如果能满足数据一致性的要求，这也算是一种方法。