tidb在EKS集群中TiKV节点存储选型问题

【问题描述】
https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/deploy-on-aws-eks

关于TiDB在EKS部署持久化选型问题

我在tidb operator文档中读到以下内容:
“ 请使用 AWS EBS 作为生产环境的存储类型。如果需要模拟测试裸机部署的性能,可以使用 AWS 部分实例类型提供的 NVMe SSD 本地存储卷。可以为 TiKV 节点池选择这一类型的实例,以便提供更高的 IOPS 和低延迟。”

请问官方是否不推荐在EKS中为TiKV节点选用本地盘机型作为持久化存储?

如果是,选用EBS作为TiKV或TiFlash节点持久化存储与本地盘相比性能差距应该非常大吧?这样在eks部署的集群性能会和本地盘的裸机部署性能差距大概有多少?

如果不是,EKS升级或故障期间,如何保证本地盘机型被替换时,每次都等到TiKV数据迁移完毕再继续下一台?

可以支持使用本地盘作为持久化存储的,但是公有云上使用本地盘的虚拟机节点故障后,数据是无法找回的
https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/configure-storage-class#示例

具体的性能差距目前没有测试报告,如果感兴趣的可以测试一下分享到社区内。

如果不是,EKS升级或故障期间,如何保证本地盘机型被替换时,每次都等到TiKV数据迁移完毕再继续下一台? 这个问题没太理解你的意思,方便再详细描述一下么?

我注意到官方文档在EKS和GKE上是不推荐使用本地盘的,因为EKS的node生命周期的问题,对于此问题我们有什么解决方案么?


这个 TiKV 数据迁移的工作是自动的,只是在数据迁移过程中,涉及到数据同步,可能会对集群有一些性能影响。

https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/use-auto-failover

如果因eks节点重建导致本地盘数据丢失,重建期间其实是不能保证重建节点上丢失的数据在完成迁移数据后才继续重建下一台机器的。这样如果一份region的副本所在节点同时重建数据就无法恢复了,我的理解是这样所以才不建议使用本地盘。

因为如果是非k8s环境,人工操作是可以控制下线节点数据迁移完毕,再继续下一个节点操作的。

是的,那样存在一个 reigon 的多数副本丢失的情况,会导致 region 不可用

所以这块儿有点疑惑,官方文档应该考虑到类似问题了,推荐使用EBS。
但是机型推荐我记得tikv节点是需要nvme的,又只能用本地盘。

所以想问下我们有没有关于ebs和nvme本地盘性能差距的报告?
或者有没有关于在eks上运行k8s相关的最佳实践,或者如何解决并且避免上边提到的问题?

这个得看如何在性能和易维护性上做取舍了。
性能差距报告这个目前没有。
有一篇 AWS 上 kubernetes 部署 TiDB 的文档:https://aws.amazon.com/cn/blogs/china/aws-kubernetes-tidb-on-k8s-cn/
使用的也是 EBS 磁盘,可以具体测试下性能,如果 EBS 磁盘性能能够满足业务需求了,那没必要上 nvme.