一文看懂Container Attached Storage

K8S技术社区2019-03-20 11:28:13
                5月2日-4日 KubeCon + CloudNativeCon Europe 2018来了!            文末报名参与峰会直播讨论,赢取Kubernetes技术书籍!



本文给出了Container Attached Storage的简单定义,解释了这个模式是什麽,出现的原因和工作方式。


什么是Container Attached Storage?

如上图所示 ,Container Attached Storage是包含由Kubernetes编排的、基于微服务的存储控制器的软件。这些存储控制器可以在Kubernetes运行的任何地方运行,即任何云甚至裸机服务器,或者传统共享存储系统之上。关键的是,数据本身也通过容器访问,而不是存储在脱离平台的共享横向扩展存储系统中,尽管Container Attached Storage可以在这种Storage Area Network(SAN)系统之上运行。

明白了这一点,就好理解Container Attached Storage意味着解决方案的更广泛趋势(其中许多解决方案现在正由CNCF孵化),即重新创建特定类别或创建新的解决方案——构建在Kubernetes和微服务之上,并为基于Kubernetes的微服务环境提供功能 。例如,安全、DNS、网络、网络策略管理、消息传递、跟踪、日志记录等新项目已经出现在云原生生态系统中,并且通常在CNCF中出现。



类似的,Container Attached Storage通过依赖Kubernetes和其他编排器的微服务来解决许多存储用例。


为什么采用Container Attached Storage

Container Attached Storage被采用的第一个原因是它是一个基于微服务的架构,这意味着它适合构建和运行旨在加速开发(即敏捷性)的系统。就OpenEBS而言,我们看到由特定团队采用Container Attached Storage的用户可以扩展和自定义将存储策略与工作负载相匹配的能力。正如一位用户所说,如果他们只使用共享存储,工作负载必须与正在使用共享存储的其他工作负载相抗衡,并且必须经过所谓的“I / O混合器”。而通过添加OpenEBS,他们可以决定自己块的大小、复制模式、备份策略等,而且不必向中央存储申请许可。使用Container Attached Storage时,默认的部署模式是超融合的,数据保存在本地,然后复制到其他主机。

Container Attached Storage被采用的第二个原因是由于许多企业和组织避免锁定的战略决策。当然,这种避免锁定的愿望似乎是采用Kubernetes的推动力之一,它“随处运行”并确保编排框架本身不会成为难以摆脱锁定的源头。


Kubernetes不足的地方,Container Attached Storage可以补上。如果Container Attached Storage的构建方式不依赖于内核修改,那么确实可以跨云跟上工作负载;实际上,可以在Container Attached Storage的帮助下迁移工作负载。无状态工作负载相对容易“移动”,有状态的工作负载需要在移动之前耗尽,并且它们所依赖的数据也必须移动。来自OpenEBS和其他公司的Container Attached Storage越来越能够在后台进行这种数据迁移,以便解决由于”数据重力“导致的云锁定问题。

Container Attached Storage采用的第三个原因与第一个有些相关,即直连存储现在通常是工作负载、应用架构和架构师所假定的模式。Container Attached Storage可以提供“刚好足够”的存储管理功能,无需在不熟悉SAN和其他共享存储的环境中引入共享存储的“反模式”。具有讽刺意味的是,Container Attached Storage采用的一种方式是在OpenShift或其他一些由共享存储支持的Kubernetes环境之上运行。尽管如此,对于开发人员和工作负载而言,Container Attached Storage在性能和故障域方面看起来更像DAS,而不是共享存储。


Container Attached Storage 如何工作?


现在有各种各样的Container Attached Storage解决方案,包括PortWorx和StorageOS以及OpenEBS,每个都有自己的优势和弱点。这些解决方案在构建和部署方式上具有一些共同的特点。


第一个共同特点是Container Attached Storage解决方案由在Kubernetes(有时还包括其他编排层)之上运行的微服务组成。这意味着传统的存储控制器已经被分解成可以独立运行的组成部分。由于利用了Kubernetes抽象或原语,高可用性和水平可伸缩性的许多问题都是“免费”解决的。


第二个共同特点是,由于每个工作负载都有自己的一个或多个控制器,它们尽可能少地集中I / O,因此避免了上述“I / O混合器”。为什么这一点非常重要?输入/输出操作可能成为有状态工作负载性能的瓶颈,而该有状态工作负载的性能可能成为应用程序性能的瓶颈。换句话说,当你在你最喜欢的旅游网站上点击“购买”时,交易发生的速度可能与底层存储的I / O性能直接相关。事实证明,当涉及到I / O时,应用程序有不同的需求,而且将这些I / O集中到一起会显著降低性能。例如,有些系统实际上会更受到吞吐量的限制(而不是I / O),会向媒质写入大块,而有些系统将更受到I / O的限制,会向媒质写入小10或100倍的较小块。

一个简短的题外话:当共享横向扩展存储被开发出来时,它可以加速性能(与单一系统直连存储相比),并且通过将分布式系统管理的挑战集中到一个独立的系统中,简化了管理。现在,共享存储几乎总是比DAS系统慢一个数量级甚至更多,而且这种差距只会越来越大。此外,现在我们所做的都是分布式系统,而这就是云原生架构,因此再有一个微服务环境下的、行为不同的分布式系统并没有多少好处,有时候还被视为“反模式”。


结论和下一步是什么?

这篇文章旨在回顾对为Kubernetes用户提供支持的我们来说,哪些是显而易见的,如微服务、容器化,以及Kubernetes为数据的管理和存储方式所开辟的一些新的可能性。虽然共享存储肯定会继续存在很长时间 ( 它作为IT堆栈中最昂贵和最传统的部分,地位不容忽视),但Container Attached Storage正在兴起,它提供控制和性能水平,提供许多微服务有状态工作负载和企业采用云服务所需的不被云锁定的自由(通常通过扩展底层共享存储的功能)。


 


2018年5月2日-4日,云原生计算基金会旗舰会议KubeCon+CloudNativeCon将于丹麦哥本哈根举行,届时来自全球领先的开源和云原生社区的采用者和技术专家汇聚一堂。


K8S技术社区联合EasyStack技术团队亲赴峰会现场,为大家带来峰会一手资讯+现场评论+直播分享,长按识别二维码报名参与K8S技术社区峰会直播讨论,有机会获得由K8S技术社区赞助的Kubernetes技术书籍



Copyright © 古田计算器虚拟社区@2017