首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >块存储、对象存储、文件存储, 容器存储的最佳方式应该是什么?

块存储、对象存储、文件存储, 容器存储的最佳方式应该是什么?

原创
作者头像
焱融科技
修改2020-02-28 14:16:15
4.3K0
修改2020-02-28 14:16:15
举报
文章被收录于专栏:焱融科技焱融科技

容器的无状态临时存储是一个很好的特性。从镜像启动一个容器,修改,停止,然后重新启动一个容器。一个全新的跟镜像一模一样的容器回来了。

让我们以一个Hello World为例,在Docker中,我们可以这样做:

# docker run -it centos
[root@c42346f95m9b /]# echo "Hello world" > /hello-file
[root@c42346f95m9b /]# exit
exit
# docker run -it centos
[root@q07h8716fah8 /]# cat /hello-file
cat: /hello-file: No such file or directory

当我们将应用系统容器化时,临时存储非常的有用。一是很容易水平扩展:我们只需要从相同的一个镜像创建多个容器即可, 每个容器都将拥有独立的文件系统。二是升级容易:只要从新的镜像创建新的容器即可,而无需关心原地升级。这使得从一个系统升级为集群更加容易,甚至只要拥有一个可访问的镜像仓库,就可以完成从私有环境向公有云环境的迁移。同时,系统恢复也更加容易,我们不需要关心应用在Crash的时候,应用对文件系统做了什么,仅仅是启动一个全新的干净的容器镜像,就好像灾难从没发生过一样。

但Hello World和真实生产应用之间还是存在很大差异。真实的应用必须要保存状态,例如应用日志如何保存,应用的资源文件如何保存,或者要将数据保存到数据库中,可能是关系型数据,也可能是非关系型数据。那么很自然的,数据库运行在哪里?容器是一个合适的选择,因为这样就可以利用到容器的升级、水平扩展,以及其它种种特性。这时临时存储不再符合要求,容器需要能够访问到持久化存储来保存必要的数据。

以本地文件系统为例,从容器的角度示例如下:

# docker volume create data
data
# docker run -it -v data:/data centos
[root@5532794097ue /]# echo "Hello world" > /data/hello-file
[root@5532794097ue /]# exit
exit
# docker run -it -v data:/data centos
[root@982638234d1 /]# cat /data/hello-file
Hello world

在上面的例子中,容器保留了数据卷,当数据卷被挂载到新的容器实例时,文件内容仍然存在。但这种方式只适合单机容器环境,当运行环境是容器集群的时候,容器可在集群中的任何一台服务器上运行,也可能从一台服务器迁移到另外一台服务器上,这意味着容器数据卷无法依赖某一个服务器的本地文件系统,我们需要一个对容器感知的分布式存储系统。

有了这样的需求和背景,我们来看一看容器需要的存储究竟应该是什么样的。

冗余性

迁移应用到容器编排平台的一个原因就是我们可以由很多的节点,在集群环境中能够容忍某些节点的故障。基于同样的考虑,我们也希望存储也能够容忍磁盘或者节点的故障,使上层的应用持续的运行。冗余对于存储来说尤为重要,因为我们不能忍受数据的丢失。

分布式

分布式方案能够更好地支持冗余性,同时也有助于性能的提升。当我们的容器集群达到上百台规模时,我们并不期望所有的数据只是落在有限的若干磁盘上。当集群需要跨地域来降低上层用户的响应延迟时,用户也期望数据也能够跨地域存在。

动态性

容器应用是在持续变动中存在的,例如新版本的发布、滚动更新、测试版本的创建等等。在这样的应用特点需求下,要求对应存储的创建与删除也相应的是动态的,并且是支持声明式创建的方式。

透明性

容器存储需要满足各类应用的需求,这意味着存储接口应该是原生的,无论是一个文件系统,还是成熟的API接口。

如果您看过Kubernetes社区的存储支持列表,会发现里面有众多的存储实现,但我们可以分为如下的三类:

纵然有如此多的容器存储列表,又有如此多的存储分类,到底哪种存储应该成为容器存储的最佳选择呢,我们从容器应用的类型来逐步分析:

一种是传统的应用,例如各种现存的应用程序,需要访问数据库,或访问文件目录等。暂且不说Oracle, SQL Server等大型数据库,因为即使技术能够满足,客户能否接受还需要时间考量,对于MySQL以及其它同类型中间件而言,从我们实际测试的效果看,YRCloudFile文件系统支持MySQL容器应用的性能,并不比块存储作为MySQL容器存储的性能差。

二是新兴的应用,如AI , 大数据分析等,典型的场景就是海量的非结构数据分析和处理。在这些场景下,文件数量可达到几十亿规模,块存储的能力将变得有局限。此外,类似机器学习等使用GPU资源的任务类型,需要提供足够多的客户端来进行并发的访问,才能够更加充分地利用GPU资源,很显然,一个能支持海量文件且具备良好性能的文件系统是一个很好的选择。

焱融容器存储YRCloudFile作为国内第一家进入CNCF LandScape Container-Native Storage容器存储图谱的容器存储产品,设计的初衷就是解决容器化应用对存储的访问需求,例如在Kubernetes环境中等。除了日常对接容器所需的功能,YRCLoudFile满足了上面提及的所有容器存储所需要的特性,提供CSI、FlexVolume的插件,支持多挂载、配额、扩容等特性,YRCloudFile还支持如下功能:

  • 子目录挂载。通过集群内可挂载目录的设置,管理员可以控制哪些文件目录可以被哪些节点访问,同时也可以控制相应节点的读写权限。
  • YRCloudFile在数十亿小文件规模下,无论文件操作(考验元数据处理能力),或者是小文件读写带宽(考验元数据处理和存储的并发访问性能),都保持平稳的性能。相较于其它传统的云原生存储或分布式文件存储,YRCloudFile在海量小文件的支持上,都具有优势。对于新兴的AI等场景可以做到很好的支持。
  • 当前的应用一方面带来庞大的数据量,而另一方面,并非所有的数据都是作为应用的热数据随时需要访问。YRCloudFile支持根据策略的定义,自动将符合条件的非经常访问数据移动到冷数据层,既提供了统一命名空间的全局访问,又达到了降低总体成本的目的。

通过这篇文章,我们可以看到虽然容器存储的类型有很多,但众览全局,结合应用的特点、新类型应用的出现,高性能的分布式文件系统更能满足持久化容器应用的需要。焱融YRCloudFile一直专注于成为容器场景下的高性能文件系统,也将更加地深入分析新型应用的特点,提高容器存储的效率和性能。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 冗余性
  • 分布式
  • 动态性
  • 透明性
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档