你好,游客 登录
背景:
阅读新闻

容器“死了”,数据依然“活着”,三分钟解密容器持久化存储

[日期:2016-12-29] 来源:  作者: [字体: ]

单体应用强调文字

在应用发展初期,通常都是单体应用,通俗来说就是系统只有一个应用,相应地,所有业务逻辑代码打包放在一个代码库中并统一部署。​​

单体应用采用模块化的分层架构,Web层负责用户交互,App层负责业务逻辑,DB层负责数据移除 单体应用采用模块化的分层架构,Web层负责用户交互,App层负责业务逻辑,DB层负责数据。

看起来的确简单。

但随着市场的快速发展,业务规模、参与人数、系统复杂度、代码腐化程度都不断攀升,传统单体架构渐渐深陷泥淖。

传统单体架构的局限性

1. 开发效率低:所有开发在一个项目里改代码,递交代码相互等待,代码冲突不断

2. 代码维护难:代码功能耦合在一起,新人不知道何从下手

3. 部署不灵活:构建时间长,任何小修改必须重构整个项目,而且过程漫长

4. 稳定性不足:一个微不足道的小问题,可以导致整个应用挂掉

5. 扩展性不够:无法满足高并发情况下的业务需求

用户迫切需求更加敏捷高效的软件交付方式。随着虚拟化、分布式技术的发展成熟,催生应用架构先后演进出分布式服务框架、SOA服务化架构,以及今天非常流行的微服务架构。

基于容器的微服务架构

微服务架构,简单来说就是把原本单一的应用按照功能边界拆分成一系列独立、专注的微服务,当然微服务之间可以轻量通信,这是比SOA更彻底的拆分。而容器所提供的轻量级、面向应用的虚拟化运行环境为微服务提供了理想的载体。​

基于容器的微服务架构,极大简化了容器化微服务创建、集成、部署、运维的整个流程,从而推动微服务在云端的大规模实践。

微服务架构的优势

1. 小,且专注于做一件事

2. 松耦合、独立部署

3. 轻量级通信机制

4. 多语言支持,易于引入新技术

5. 更好的可扩展性和鲁棒性

下面这张图直观明了地展现了应用部署方式的演进历程。

微服务架构下的容器存储挑战

问题核心:有状态应用的持久化存储

有道是麻绳易在细处断,想要从基于容器的微服务得到最大的敏捷性和适应性,就必须使“有状态服务”的速度和可移植性达到与“无状态服务”相同的标准。

一般看法认为容器对于无状态的应用程序是很好的,但是不适合有状态应用,首当其冲就是“持久化存储”的问题。在生产环境中,如何实现容器持久化存储一直是业界的热点问题。

​有状态应用的容器存储需求

1. 数据持久化

2. 跨团队副本共享

3. 灾难恢复

4. 数据管理

5. QoS

容器持久化存储的实现方案

Cloud Native · 容器作为VM · 持久化卷

1. Cloud Native

​按照纯粹的云原生设计模式,持久化数据并不是存储在容器中,而是作为后端服务,例如对象存储和数据库即服务。这个方案可以确保容器和它们后端的数据持久化服务松耦合,同时也不需要那些会限制扩展的依赖。弹性不是通过诸如网络存储这种共享架构提供,而是通过应用运行在容器中并配合容器管理平台来实现。

2. 容器作为虚拟机

​为了利用容器带来应用便携性的优点,将容器作为轻量虚拟机来使用。该方案中,一部分是直接采用遗留应用,如Oracle,将它们从虚拟机迁移到容器里。这包括挂载共享网络存储卷到容器中作为数据库存储使用。

局限性

在这种架构下,如果重启一个容器,甚至一个共享存储,已经不同于在Hypervisor中重启虚拟机的核模式。

当一个容器在一个新的容器宿主机上重启,它期望的是这个应用能通过重启来恢复并重连到数据库卷。相比之下,遗留应用假定基于VM的基础架构来实现恢复,并不涉及应用。

如果便携性是迁移到容器的原因之一,那么采用容器替代虚拟机来安装遗留应用是这种便携性的反模式。由于大卷中存储数据是紧耦合在容器上,便携性难以实现。

像这样的限制使得一个虚拟机直接容器化存在很多问题。

3. 容器持久化数据卷

在容器中运行的应用,应用真正需要保存的数据,可以写入持久化的Volume数据卷。在这个方案中,持久层产生价值,不是通过弹性,而是通过灵活可编程,例如通过优秀设计的API来扩展存储。这个方案结合了持久层和或多或少的纯云原生设计模式。目前,主要支持Docker或Kubernetes的Volume。

​Docker的容器卷插件

Docker发布了容器卷插件规范,允许第三方厂商的数据卷在Docker引擎中提供数据服务。

这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准,就可接入Docker容器的运行平台中。

现有的各种存储可以通过简单的驱动程序封装,从而实现和Docker容器的对接。可以说,驱动程序实现了和容器引擎的北向接口,底层则调用后端存储的功能完成数据存取等任务。

目前已经实现的Docker Volume Plugin中,后端存储包括常见的NFS,CIFS,GlusterFS和块设备等。

K8s的数据卷

K8s的每个Pod包含一个或多个容器。Pod可部署在集群的任意节点中,存储设备可通过数据卷提供给Pod的容器使用。

为了不绑定特定的容器技术,K8s没有使用Docker的Volume机制,而是制定了自己的通用数据卷插件规范,以配合不同的容器运行来使用(如Docker和rkt)。

数据卷分为共享和非共享两种类型。其中非共享型只能被某个节点挂载使用(如iSCSI,AWS EBS等网络块设备);共享型则可让不同节点上的多个Pod同时使用(如NFS,GlusterFS等网络文件系统,以及可支持多方读写的块设备)。对有状态的应用来说,共享型的卷存储能够很方便地支持容器在集群各节点之间的迁移。

为了给容器提供更细粒度的卷管理,K8s增加了持久化卷的功能,把外置存储作为资源池,由平台管理并提供给整个集群使用。K8s的卷管理架构使得存储可用标准的接入方式,并且通过接口暴露存储设备所支持的能力,在容器任务调度等方面实现了自动化管理。

结束语

这两年容器技术的大爆发深刻变革了企业构建、交付和维护软件的方式。容器技术与微服务的结合,更是将敏捷性、适应性提高到一个新高度。但挑战依然存在,尤其是“数据库”方面,因为如果存储方案不能与容器进行良好配合,由微服务革命所带来的优势也就难以尽情发挥。

当下容器持久化存储依然有待发展和成熟,天玑数据希望与广大同行一起努力,从而加速企业的容器和微服务革命。

收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款
热门评论