文章插图
文章插图
简介: 以上为大家分享了阿里云容器存储的技术创新 , 包括 DADI 镜像加速技术 , 为容器规模化启动奠定了很好的基础 , ESSD 云盘提供极致性能 , CNFS 容器网络文件系统提供极致的用户体验 。
作者:徐立
云原生的创新源泉
云原生趋势下 , 应用容器化比例正在快速增长 , Kubernetes 也已成为云原生时代新的基础设施 。Forrester 预测到 2022 年 , 全球组织/公司在生产环境运行容器化应用 。从今天不足 30%的比例将大幅度提升到超过 75% , 企业应用容器化的趋势势不可挡 。我们可以看到两个普遍的现象 。首先 , 在云上托管 Kubernetes 已经成为企业上云及运行容器的优先选择 。另外 , 用户使用容器的方式也在改变 , 从无状态应用到核心企业应用再到数据智能应用 , 越来越多的企业使用容器来部署生产级别、复杂度高和高性能计算的有状态应用 。比如 Web 服务、内容资料库、数据库 , 甚至 DevOps、AI/大数据应用等 。
随着基础设施从物理机到虚拟机 , 到以 Kubernetes 为代表的容器环境 , 甚至到 Serverless 的逐渐演进 , 今天的计算和应用正在面临巨大的变化 。这种变化使得资源粒度越来越细 , 生命周期越来越短 , 计算按需使用 。
从用户视角来看云原生带来的存储变化 , 最明显的就是用户使用存储界面发生上移 , 和应用不直接相关的存储服务从应用层下沉到云平台 , 用户更关心应用 。
举例来说 , 传统形态用户需要关心所有硬件和软件 , 逐渐过渡到用户关心虚拟机、操作系统和整个应用软件栈 , 到今天在 Serverless 里演变成用户只关心应用业务和代码 。系统资源从物理资源层、虚拟化资源层上升到应用开发层 , 用户无需关心底层的基础设施 。
在这样的技术体系下 , 存储的能力的演变主要体现在以下 3 个方面:
1、高密虚拟机时代 , 一个虚拟机就对应一个完整的存储空间 , 可以用其存储整个应用所需要的所有数据相关的访问和存储需求 。在Serverless 函数计算环境 , 应用被切分为一个个函数 , 对应的资源都需要存储管理 , 因此 , 存储的密度发生了很大的变化 , 存储密度更高 。
2、弹性随着应用拆分的粒度越来越细化 , 存储密度逐渐提升 , Serverless 函数计算大规模实例需要高并发启动 , 存储需要极致弹性的能力 。
3、极速从Serverless 函数计算的角度来看 , 函数是整个进程的一个部分 , 生命周期自然变短 。由此出现大量短生命周期的容器实例 。随着生命周期越来越短 , 需要存储快速挂载/卸载 , 快速访问 。
随着服务界面发生上移 , 存储管控界面被重塑 , 内置存储和外置存储变得更加清晰 。Serverless 环境里 , 用户可见界面是外置存储(包括文件存储和对象存储) , 而内置存储(包括镜像存储和临时存储)对用户是不可见的 , 内置存储由阿里云来管理 , 提供了创新的机会 。
镜像加速的技术创新
阿里巴巴容器规模化部署的挑战
阿里巴巴容器规模化部署主要面临的挑战体现在以下几个方面:
1、业务体量大 。集群规模大 , 高达十万量级;所有应用全部容器化 , 并且应用镜像大 , 通常以数十 GB 大小为主 。
2、更快的部署速度 。业务规模持续增长 , 要求云平台可以快速的部署应用 , 才能够处理业务增长 , 尤其双十一大促时紧急扩容 , 难以事前对各服务准确预估容量 。
3、然而大规模的创建或者更新容器集群依然很慢 , 主要原因是容器部署镜像的下载和解压很慢 , 主要的技术挑战如下:
时间开销大:时间开销 ∝ 镜像大小 * 节点数;一千节点就需要存一千份镜像;CPU 时间开销大:gzip解压慢 , 且只能串行解压;I/O 压力大:下载、解压两轮写盘 , 包括众多节点同时写盘 , 对云盘产生“共振”;内存占用扰动:对宿主机 page cache 产生严重扰动;但是有效数据占比少:启动时平均仅需镜像数据的6.4% 。
应对以上技术挑战 , 大规模容器部署的关键需求抽象总结为三点:
1、按需:下载解压速度足够快、数据按需访问和按需传输 。
2、增量分层:数据解耦 , 通过 OCI-Artifacts 标准 overlayfs 把层次做划分 , 增量数据 , 时间资源使用更有效 。
3、Remote Image :采用远程镜像技术 , 改变镜像格式 , 同时减少本地资源的消耗 。
Remote Image 技术方案对比
Remote Image 主要有两种技术实现的方式 , 一种是基于文件系统 , 第二种是基于块设备 。Remote Image 技术方案对比如下图所示:
基于文件系统的 Remote Image 技术的主要特点是直接提供文件系统接口 , 是容器 Image 的自然扩展 。复杂度高 , 稳定性、优化和高级功能的实现难度大 。在通用性上 , 和操作系统绑定 , 能力固定 , 不一定匹配所有应用 。同时攻击面较大 。行业代表主要是 Google CRFS , Microsoft Azure Project Teleport , AWS SparseFS 。
基于块设备实现的 Remote Image 技术的主要特点是可配合常规文件系统一起使用 , 如 ext4;普通容器、安全容器、虚拟机均可直接使用 。复杂度、稳定性、优化和高级功能更容易实现 。在通用性上 , 与操作系统和文件系统解绑 , 应用可自由选择最合适的文件系统 , 如 NTFS , 作为依赖打包进 Image 。并且攻击面较小 。
阿里巴巴选择了 Date Accelerator for Disaggregated Infrastructure (简称为 DADI) , 同时进行了规模性验证 。
阿里巴巴自研容器镜像加速技术 DADI
DADI 是阿里巴巴的独创性的技术方案 。DADI 镜像服务是一种可以做到敏捷又弹性部署应用的分层块级镜像服务 。DADI 彻底摒弃了传统容器启动的瀑布类型(即下载、解包、启动) , 实现了远程镜像的细粒度按需加载 , 容器启动前不在需要部署镜像 , 容器在创建后可以立即启动 。
DADI 的数据路径如下图所示 , 虚线之下是内核态 , 虚线之上是用户态 。DADI 将镜像抽象为虚拟块设备 , 并在其上容器应用挂载常规文件系统如 ext4 。当用户应用读取数据时候 , 读取请求先通过常规的文件系统处理 , 文件系统将请求转换为虚拟块设备的一次或者多次读取 。对块设备的读取请求被转发到用户态的 DADI 模块 , 最后转换为一个或者多个 Layer 的随机读取 。
DADI 镜像采用块存储+分层技术 , 每层只记录被增量修改的数据块 , 支持压缩以及实时的按需解压缩;支持按需传输 , 只传输用到的数据块下载使用;DADI 还可以采用 P2P 传输架构 , 一传十、十传百 , 在大规模集群内将网络流量均衡到所有多个节点上去 。
DADI 关键技术解读
DADI 增量镜像可以通过基于块+分层技术来实现 , 其中每个层对应于一个 LBA 的变更 。DADI 的关键技术包括远程镜像的细粒度按需传输 , 高效的在线解压缩 , 基于 trace 读取 , 用于处理突发工作的 P2P 传输技术 。DADI 在提高部署应用的敏捷性和弹性方面非常有效 。
1、分层块设备 Overlay Block Device
每层记录被增量修改的变长数据块 LBA , 不涉及文件/文件系统的概念 , 以 512 字节为最小粒度 。快速索引 , 支持变长记录 , 以节省内存 , 各记录的 LBA 不重叠 , 支持高效的区间查询 。
2、原生支持可写层
提供追加写文件和随机写稀疏文件两种模式构建 DADI 镜像 。只读层 , 每个只读都可以按照不同类型的大小 , 每层查询区间 , 速度极快 。可写层由存储原始数据(Raw Data)和存储索引(Index)两部分组成 , 接受 append only 组织而成 。
3、ZFile 压缩格式
标准压缩文件格式 , 例如 gz , bz2 , xz 等 , 无法高效的进行随机读写操作 , 无论读取压缩文件中的哪一部分 , 都需要从头部开始解压 , 为了支持 layer blob 的压缩并同时支持远程镜像的按需读取 , DADI 引入了 ZFile 压缩格式 。ZFile 的压缩格式如下图所示 , 按固定大小数据块压缩 , 只解压读到的数据块 , 支持多种有效的压缩算法 , 包括 lz4 , zstd , gzip 等 , 采用通用格式 , 不绑定于 DADI 。
4、基于 Trace 预取
记录应用过程中的读取日志、只记位置、不记数据本身 。在应用冷启动时 , 若已有 trace 记录 , 则 DADI 将根据trace提前把数据预取回本地 , 采用高并发读取 , 更加高效 。Trace 作为一个特殊的 layer 存于 image , 专门用于加速 , 用户不可见 , 未来可容纳其他加速文件 。如下图绿色部分表示加速层、容纳 trace 文件以及其他文件 。
5、按需 P2P 传输
在我们的生产环境中 , 有几个关键应用程序已经部署在数千台服务器上 , 并且包含高达数 GB 的 Layer , 这些应用程序的部署给 Registry 和网络基础设施带来了巨大压力 。为了更好的处理此类大型应用 , DADI 将最近使用的数据块缓存在每个宿主机的本地磁盘上 , 采用 P2P 的方式在主机之间传输数据 。
1、采用树形拓扑结构分发数据
各个节点均缓存最近使用过的数据块跨节点请求大概率命中父节点自己的 cache未命中的请求会递归向上传递 , 直到 registry
2、拓扑结构由 root 节点动态维护
每个 layer 单独一个传输拓扑
3、每个机房单独部署一组 root
多节点高可用架构基于一致性哈希的分工大规模启动耗时测试
我们将 DADI 容器启动延迟与 .tgz 镜像、Slacker、CRFS、LVM 和 P2P 镜像下载进行了比较 , 使用 DockerHub.com 上的 WordPress 镜像 , 我们观测单实例的冷启动延迟 , 所有服务器和主机位于同一数据中心 。如左图所示 , 结果表明 , 使用 DADI 可以明显减少容器的冷启动时间 。
我们在公共云上创建了 1000 个 VM , 并将他们用做容器的主机 。在每个主机上启动 10 个容器 , 总共 10000 个容器 。测试使用 Python 编写的一个小程序 Agility , 访问 HTTP 服务器并在服务端记录时间 。如右图所示 , 结果表明 DADI 的冷启动在 3 秒之内快速完成 。
DADI 在阿里巴巴的规模化运行
DADI 已经在阿里巴巴集团规模化运行 , 在阿里巴巴的生产环境内大规模部署 。数据显示 DADI 在 10000个宿主机上启动 10000 个容器仅需3-4 秒 。DADI 完美应对双十一大促洪峰 , 目前在阿里巴巴集团内部已经部署了接近十万台服务器宿主机 , 支持集团 Sigma、搜索、UC 等业务在线、离线应用超过 2 万个 , 极大提高了应用发布、扩容效率 , 体验如丝般顺滑 。我们在全球最大的电子商务平台之一的生产环境中使用 DADI 的经验表明 , DADI 在提高部署应用的敏捷性和弹性方面非常有效 。
拥抱开源 , 释放云原生技术红利
现在 , DADI 正在通过贡献社区的方式更好地释放云原生技术红利 , 也希望与更多企业和开发者共建容器镜像标准 。
目前 DADI 已经开放了支持 Contained(docker 尚不支持 remote image) , 支持节点直连 Registry + 本地缓存技术 , 支持构建、转换镜像 。
未来还会开放 P2P 按需传输:将 P2P 子系统重新设计为 Registry 的延伸 , 将支持共享存储 , 如 nfs、hdfs、ceph、glusterfs 等 , 全局 Registry +机房共享存储 + 节点本地缓存 + P2P 数据传输 , 构建机房内缓存 。
大家可通过查看以下 Github 的链接了解更多信息:
【阿里云图片存储 免费吗 阿里云盘照片】控制平面 (for containerd):