【技术干货】云原生海量数据存储系统设计浅谈

{"value":"\n\n##### **01 背景**\n\n为了更好解决诸如社交平台这种云原生业务对计算和存储的需求问题，本文介绍一种新的存储系统，称之为 Kubestorage，指运行在 Kubernetes 上的存储系统。该系统基于 Haystack（一种对象存储模型），但在服务发现和自动容错等宏观调度方面进行了专门优化，使其更符合云原生技术的定义，更适合部署在云端，也更适合于在存储方面驱动数据密集型的云业务高效稳定运行。此外还针对 Haystack 于磁盘方面的性能瓶颈，在缓存与易用性方面进行了优化。\n\n##### **02 什么是云原生**\n\n有些业务从设计之初即计划运行在云端，这些业务通常被称作云原生业务，意指其与云的高度结合。云原生业务相对传统业务通常会更加充分且频繁地应用例如微服务、弹性计算和服务编排等云平台所提供的先进技术帮助业务更稳定、高效地运行。部分前沿实践甚至尝试使用更加轻量的操作系统（如 Alpine Linux 等）来适应容器化和虚拟化技术。\n\n\n\n\n\n##### **03 什么是面向对象存储系统**\n\n\n\n\n对象存储，也可以被称作“云存储”，核心是把文件作为一个个的对象，存储在互联网上，相较于普通的存储方式，对象存储的特点是具有封装性，在对象存储系统中，不能对文件直接进行打开和修改的行为，但是可以像 FTP 一样上传和下载文件。对象存储系统中的数据管理方式，不是常见的以文件目录方式管理，而是基于策略的自动化管理，将对象全部放入“桶”（存储空间）中，通过“桶”和对象的 ID 实现查找和访问，是一种非常扁平化的存储方式。\n\n\n\n**对象存储的发展历程：**\n\n1996年，卡内基梅隆大学就开始了由 Garth Gibson 领导的相关研究，并于1998年首次提出了对象存储的概念与基础架构。此后，对象存储在各存储公司的支持下持续蓬勃发展。\n\n在2006年，美国亚马逊公司旗下的亚马逊云科技(Amazon Web Services)将对象存储作为开放服务，开发了亚马逊 S3 对象存储服务。仅2012年一年，S3 对象存储系统就新增了超过一万亿个对象。此外，S3 还能确保这些数据可以随时被访问与随机读写。据亚马逊官方报告，S3 中的任意一个文件都可以承载每秒最高110万次的读取。\n\n在2010年 Facebook 公司通过论文的形式提出了一种专注于大量小文件的存储、更实用且更灵活的对象存储模型，称之为 Haystack。Haystack 的独特之处在于将小文件合并到一个称为物理卷的文件块中，以便在存储大量小文件的同时保持较为理想的索引速度。 \n\n##### **04 Kubestorage 的架构**\n\nKubestorage 架构由武汉理工大学刘福鑫，李劲巍，王熠弘，李琳于2020- 02-10发表于《计算机应用》\n\nKubestorage 存储系统由三部分组成：\n\n1）目录服务器，用于节点信息的存储、文件到存储节点的映射、节点自动管理与负载均衡等功能。\n\n2）存储服务器，用于文件存储、元数据管理和存储一致性的自动维护。\n\n3）缓存服务器，用于缓存高频访问的文件，以获得更好的性能。\n\n整个存储系统运行在以 Docket 为容器后端 Kubernetes 集群之上，通过 Kubernetes 配置文件的方式进行快速部署，Kubernetes 负责提供管理、服务发现与故障恢复等功能。\n\nKubestorage 的详细架构如图所示，主要由目录服务器、存储服务器和缓存服务器三个部分组成。\n\n\n\n**目录服务器**\n\n目录服务器主要承担以下工作：\n\n1）管理逻辑卷和物理卷之间的映射；\n\n2）管理目录服务器级别缓存；\n\n3）当某个文件访问量激增时，开启自动文件冗余，在多个存储服务器上建立该文件的副本以提升吞吐能力；\n\n4）作为负载均衡器，对存储服务器进行反向代理，并向外部业务提供统一的 API 。\n\n**存储服务器**\n\n存储服务器主要承担以下工作：\n\n1）负责管理存储在其中的文件、文件的元数据以及文件的写入和读取；\n\n2）管理存储服务器级别缓存；\n\n3）执行数据压缩、解压缩与有效性校验；\n\n4）定期向目录服务器报告其状态，以便根据统计信息进行自动化管理。\n\n**缓存服务器**\n\n缓存服务器负责统一的数据缓存，由于需要存储文件，因此使用 Redis 作为其存储后端，从内存中进行文件读写以保障性能。缓存服务器使用了目录/存储两级缓存设计，以提升缓存性能，尽量降低响应时间与服务器负载。\n\n##### **05 文件的上传流程**\n\n\n将文件上传到 Kubestorage 的过程:目录服务器首先接收来自业务的文件上传请求，其中包括文件的副本次数和文件的二进制数据。如果当前目录服务器不是 Leader 服务器，则受理上传请求的目录服务器将向Leader服务器发送一个反向代理请求。Leader 服务器将会核对数据库，以确保物理卷数量足够，然后创建区块和存储数据的请求将被发送到指定的存储服务器。目录服务器最后生成对应链接以便后续访问。\n\n\n\n##### **06 文件的下载流程**\n\n\n\n\n从 Kubestorage 下载文件的过程:首先业务将向目录服务器发送文件下载请求，请求中包含此前所生成的永久链接，目录服务器首先将检查文件是否存在于目录缓存中，如果文件存在，数据将从内存中读取，并直接传输给业务；如果未命中缓存，则会将文件获取请求发送到相应的存储服务器，存储服务器同样将检查文件是否存在于存储级缓存中，如果在存储级缓存中则直接传输，如果缓存未命中，则存储服务器会将当前文件放在存储级缓存中，以此减少下次读取时间，如果频繁访问该文件，它还会被转移到目录级缓存进一步提高文件的访问速度。\n\n\n\n##### **07 对服务器故障节点的处理**\n\nKubestorage 能容许服务器节点的故障并能实现自动恢复。每台目录服务器都会通过kube-apiserver组件定时获取当前所有节点状态，若发现某台服务器出现异常（即 Kubernetes 自检不成功，Pod 状态为 NotReady或状态标签为 Offline），目录服务器会立刻调用 kube-apiserver 清除故障节点并完成持久卷绑定、数据库初始化等操作，实现自恢复。该策略对目录服务器、存储服务器与缓存服务器均有效。\n\n\n\n##### **08 Kubestorage 的性能**\n\n我们可与 EXT4,ZFS 和 SeaweedFS 作比较，它们分别代表传统文件系统、现代文件系统和传统对象存储系统。\n\n我们发现，当并发读取量较低时Kubestorage,SeaweedFS 的读取性能与 EXT4 大致相同。当并发读取量上升后，Kubestorage 开始逐渐展现出其优势，在读取时，Kubestorage 受益于其多级内存缓存与自动建立副本的设计，相对 SeaweedFS 性能更占优势。Haystack 存储结构的 Kubestorage 与 SeaweedFS 性能均优于 EXT4 和 ZFS，其中 Kubestorage 由于缓存与自动副本策略的引入，性能相对更优。\n\n下图为 Kubestorage 的读取性能随并发读取量的变化，以线程数50与5000对40KB的文件进行读取的读取情况为例。\n\n\n\n\n\n由于创建元数据和将文件插入物理卷的开销较大，Kubestorage 和 SeaweedFS 的写入性能均远低于其他文件系统，这一问题在请求数量增多时格外明显。\n\n下图显示了以线程数为50，写入40KB大小的文件时的写入性能。\n\n\n\n在热点访问测试过程中，由于 EXT4,ZFS,SeaweedFS 均不带有文件缓存，在不同测试阶段的性能并无显著变化，但 Kubestorage 随着访问计数的不断增加开始逐渐开启副本冗余、写入缓存，以降低存储服务器的磁盘压力。缓存策略为 Kubestorage 带来了性能与稳定性提升。\n\n\n\n##### **09 Kubestorage 的稳定性**\n\n\n若作为当前 Raft 集群的 Leader 的目录服务器被关闭, Kubernetes 的负载均衡则将所有请求移交给另一台Follower, Follower 在节点检测过程中检测到 Leader 不可用，立刻开始新一轮选举，并将自己设置为 Leader。期间正在处理的请求被放入目录服务器队列，并在选举完成后继续请求。随后新的 Leader 在选举完成后立即调用 kube-apiserver 新建了一台新的目录服务器以填补空缺，该服务器成为 Follower ，服务恢复正常。\n\n若存储服务器被关闭被关闭，则它在节点检测过程中会被目录服务器判断为不可用，并由目录服务器调用 kube-apiserver 创建新的存储服务器，自动完成持久卷挂载与数据初始化操作，然后取出所需文件传输给客户端。\n\n##### **10 展望**\n\n\n本文所说的 Kubestorage 部署过程简单，使用预配置的脚本仅需数条命令即可搭建出任意规模的Kubestorage存储集群，这使其更为灵活，在云上拥有比传统存储解决方案更好的性能和更优秀的稳定性。Kubestorage 开箱即用，更适合云原生业务部署，为云上的应用提供更快捷稳定的存储解决方案。\n\n但同时我们也看到了目前 Kubestorage 所存在的一些不足，将来还需要在以下方面进行改进：\n\n1）使用缓存服务器对文件写入进行缓存，以实现异步文件保存功能，提供更好的写入性能；\n\n2）添加对目录、文件别名、软链接等高级特性的支持，以保持与传统文件系统的双向兼容和相互转换，提升兼容性与灵活度，便于让更多业务享受对象存储的便利；\n\n3）考虑到目标应用场景内可能有大量重复的文件资源，因此可对散列相同的文件进行合并存储，以节省磁盘空间。\n\n","render":"<p><img src=\"https://dev-media.amazoncloud.cn/329856c5089345fe9bb3c42d8e21300f_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"01__2\"></a><strong>01 背景</strong></h5>\n<p>为了更好解决诸如社交平台这种云原生业务对计算和存储的需求问题，本文介绍一种新的存储系统，称之为 Kubestorage，指运行在 Kubernetes 上的存储系统。该系统基于 Haystack（一种对象存储模型），但在服务发现和自动容错等宏观调度方面进行了专门优化，使其更符合云原生技术的定义，更适合部署在云端，也更适合于在存储方面驱动数据密集型的云业务高效稳定运行。此外还针对 Haystack 于磁盘方面的性能瓶颈，在缓存与易用性方面进行了优化。</p>\n<h5><a id=\"02__6\"></a><strong>02 什么是云原生</strong></h5>\n<p>有些业务从设计之初即计划运行在云端，这些业务通常被称作云原生业务，意指其与云的高度结合。云原生业务相对传统业务通常会更加充分且频繁地应用例如微服务、弹性计算和服务编排等云平台所提供的先进技术帮助业务更稳定、高效地运行。部分前沿实践甚至尝试使用更加轻量的操作系统（如 Alpine Linux 等）来适应容器化和虚拟化技术。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/361c2594c66e457f8f1b9587df62a6c9_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"03__14\"></a><strong>03 什么是面向对象存储系统</strong></h5>\n<p>对象存储，也可以被称作“云存储”，核心是把文件作为一个个的对象，存储在互联网上，相较于普通的存储方式，对象存储的特点是具有封装性，在对象存储系统中，不能对文件直接进行打开和修改的行为，但是可以像 FTP 一样上传和下载文件。对象存储系统中的数据管理方式，不是常见的以文件目录方式管理，而是基于策略的自动化管理，将对象全部放入“桶”（存储空间）中，通过“桶”和对象的 ID 实现查找和访问，是一种非常扁平化的存储方式。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/4ae32da02f3e46e8b24953d34b1c7811_image.png\" alt=\"image.png\" /></p>\n<p><strong>对象存储的发展历程：</strong></p>\n<p>1996年，卡内基梅隆大学就开始了由 Garth Gibson 领导的相关研究，并于1998年首次提出了对象存储的概念与基础架构。此后，对象存储在各存储公司的支持下持续蓬勃发展。</p>\n<p>在2006年，美国亚马逊公司旗下的亚马逊云科技(Amazon Web Services)将对象存储作为开放服务，开发了亚马逊 S3 对象存储服务。仅2012年一年，S3 对象存储系统就新增了超过一万亿个对象。此外，S3 还能确保这些数据可以随时被访问与随机读写。据亚马逊官方报告，S3 中的任意一个文件都可以承载每秒最高110万次的读取。</p>\n<p>在2010年 Facebook 公司通过论文的形式提出了一种专注于大量小文件的存储、更实用且更灵活的对象存储模型，称之为 Haystack。Haystack 的独特之处在于将小文件合并到一个称为物理卷的文件块中，以便在存储大量小文件的同时保持较为理想的索引速度。</p>\n<h5><a id=\"04_Kubestorage__31\"></a><strong>04 Kubestorage 的架构</strong></h5>\n<p>Kubestorage 架构由武汉理工大学刘福鑫，李劲巍，王熠弘，李琳于2020- 02-10发表于《计算机应用》</p>\n<p>Kubestorage 存储系统由三部分组成：</p>\n<p>1）目录服务器，用于节点信息的存储、文件到存储节点的映射、节点自动管理与负载均衡等功能。</p>\n<p>2）存储服务器，用于文件存储、元数据管理和存储一致性的自动维护。</p>\n<p>3）缓存服务器，用于缓存高频访问的文件，以获得更好的性能。</p>\n<p>整个存储系统运行在以 Docket 为容器后端 Kubernetes 集群之上，通过 Kubernetes 配置文件的方式进行快速部署，Kubernetes 负责提供管理、服务发现与故障恢复等功能。</p>\n<p>Kubestorage 的详细架构如图所示，主要由目录服务器、存储服务器和缓存服务器三个部分组成。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/382fe5a0cb054fe8b5dbdd14c836129d_image.png\" alt=\"image.png\" /></p>\n<p><strong>目录服务器</strong></p>\n<p>目录服务器主要承担以下工作：</p>\n<p>1）管理逻辑卷和物理卷之间的映射；</p>\n<p>2）管理目录服务器级别缓存；</p>\n<p>3）当某个文件访问量激增时，开启自动文件冗余，在多个存储服务器上建立该文件的副本以提升吞吐能力；</p>\n<p>4）作为负载均衡器，对存储服务器进行反向代理，并向外部业务提供统一的 API 。</p>\n<p><strong>存储服务器</strong></p>\n<p>存储服务器主要承担以下工作：</p>\n<p>1）负责管理存储在其中的文件、文件的元数据以及文件的写入和读取；</p>\n<p>2）管理存储服务器级别缓存；</p>\n<p>3）执行数据压缩、解压缩与有效性校验；</p>\n<p>4）定期向目录服务器报告其状态，以便根据统计信息进行自动化管理。</p>\n<p><strong>缓存服务器</strong></p>\n<p>缓存服务器负责统一的数据缓存，由于需要存储文件，因此使用 Redis 作为其存储后端，从内存中进行文件读写以保障性能。缓存服务器使用了目录/存储两级缓存设计，以提升缓存性能，尽量降低响应时间与服务器负载。</p>\n<h5><a id=\"05__77\"></a><strong>05 文件的上传流程</strong></h5>\n<p>将文件上传到 Kubestorage 的过程:目录服务器首先接收来自业务的文件上传请求，其中包括文件的副本次数和文件的二进制数据。如果当前目录服务器不是 Leader 服务器，则受理上传请求的目录服务器将向Leader服务器发送一个反向代理请求。Leader 服务器将会核对数据库，以确保物理卷数量足够，然后创建区块和存储数据的请求将被发送到指定的存储服务器。目录服务器最后生成对应链接以便后续访问。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/c7081a80c8884868bc77ef2e5a7ed369_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"06__84\"></a><strong>06 文件的下载流程</strong></h5>\n<p>从 Kubestorage 下载文件的过程:首先业务将向目录服务器发送文件下载请求，请求中包含此前所生成的永久链接，目录服务器首先将检查文件是否存在于目录缓存中，如果文件存在，数据将从内存中读取，并直接传输给业务；如果未命中缓存，则会将文件获取请求发送到相应的存储服务器，存储服务器同样将检查文件是否存在于存储级缓存中，如果在存储级缓存中则直接传输，如果缓存未命中，则存储服务器会将当前文件放在存储级缓存中，以此减少下次读取时间，如果频繁访问该文件，它还会被转移到目录级缓存进一步提高文件的访问速度。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/edaa4de9e4f140cb8d9e641aea67d732_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"07__93\"></a><strong>07 对服务器故障节点的处理</strong></h5>\n<p>Kubestorage 能容许服务器节点的故障并能实现自动恢复。每台目录服务器都会通过kube-apiserver组件定时获取当前所有节点状态，若发现某台服务器出现异常（即 Kubernetes 自检不成功，Pod 状态为 NotReady或状态标签为 Offline），目录服务器会立刻调用 kube-apiserver 清除故障节点并完成持久卷绑定、数据库初始化等操作，实现自恢复。该策略对目录服务器、存储服务器与缓存服务器均有效。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/d771f8ba708d489c9368523bce52a418_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"08_Kubestorage__99\"></a><strong>08 Kubestorage 的性能</strong></h5>\n<p>我们可与 EXT4,ZFS 和 SeaweedFS 作比较，它们分别代表传统文件系统、现代文件系统和传统对象存储系统。</p>\n<p>我们发现，当并发读取量较低时Kubestorage,SeaweedFS 的读取性能与 EXT4 大致相同。当并发读取量上升后，Kubestorage 开始逐渐展现出其优势，在读取时，Kubestorage 受益于其多级内存缓存与自动建立副本的设计，相对 SeaweedFS 性能更占优势。Haystack 存储结构的 Kubestorage 与 SeaweedFS 性能均优于 EXT4 和 ZFS，其中 Kubestorage 由于缓存与自动副本策略的引入，性能相对更优。</p>\n<p>下图为 Kubestorage 的读取性能随并发读取量的变化，以线程数50与5000对40KB的文件进行读取的读取情况为例。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/5ff62e0002ff4325a464bad6bea28651_image.png\" alt=\"image.png\" /></p>\n<p><img src=\"https://dev-media.amazoncloud.cn/e055c86e29c44e2580a704aa3224d2bc_image.png\" alt=\"image.png\" /></p>\n<p>由于创建元数据和将文件插入物理卷的开销较大，Kubestorage 和 SeaweedFS 的写入性能均远低于其他文件系统，这一问题在请求数量增多时格外明显。</p>\n<p>下图显示了以线程数为50，写入40KB大小的文件时的写入性能。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/564612fe143f4698ae455986c99be695_image.png\" alt=\"image.png\" /></p>\n<p>在热点访问测试过程中，由于 EXT4,ZFS,SeaweedFS 均不带有文件缓存，在不同测试阶段的性能并无显著变化，但 Kubestorage 随着访问计数的不断增加开始逐渐开启副本冗余、写入缓存，以降低存储服务器的磁盘压力。缓存策略为 Kubestorage 带来了性能与稳定性提升。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/96dc35ac1cd242e9a1d33a3efc57d7a2_image.png\" alt=\"image.png\" /></p>\n<h5><a id=\"09_Kubestorage__121\"></a><strong>09 Kubestorage 的稳定性</strong></h5>\n<p>若作为当前 Raft 集群的 Leader 的目录服务器被关闭, Kubernetes 的负载均衡则将所有请求移交给另一台Follower, Follower 在节点检测过程中检测到 Leader 不可用，立刻开始新一轮选举，并将自己设置为 Leader。期间正在处理的请求被放入目录服务器队列，并在选举完成后继续请求。随后新的 Leader 在选举完成后立即调用 kube-apiserver 新建了一台新的目录服务器以填补空缺，该服务器成为 Follower ，服务恢复正常。</p>\n<p>若存储服务器被关闭被关闭，则它在节点检测过程中会被目录服务器判断为不可用，并由目录服务器调用 kube-apiserver 创建新的存储服务器，自动完成持久卷挂载与数据初始化操作，然后取出所需文件传输给客户端。</p>\n<h5><a id=\"10__128\"></a><strong>10 展望</strong></h5>\n<p>本文所说的 Kubestorage 部署过程简单，使用预配置的脚本仅需数条命令即可搭建出任意规模的Kubestorage存储集群，这使其更为灵活，在云上拥有比传统存储解决方案更好的性能和更优秀的稳定性。Kubestorage 开箱即用，更适合云原生业务部署，为云上的应用提供更快捷稳定的存储解决方案。</p>\n<p>但同时我们也看到了目前 Kubestorage 所存在的一些不足，将来还需要在以下方面进行改进：</p>\n<p>1）使用缓存服务器对文件写入进行缓存，以实现异步文件保存功能，提供更好的写入性能；</p>\n<p>2）添加对目录、文件别名、软链接等高级特性的支持，以保持与传统文件系统的双向兼容和相互转换，提升兼容性与灵活度，便于让更多业务享受对象存储的便利；</p>\n<p>3）考虑到目标应用场景内可能有大量重复的文件资源，因此可对散列相同的文件进行合并存储，以节省磁盘空间。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/4f779247bd164326a7a7d102c213ee29_UG%E5%B0%BE%E5%B7%B4.gif\" alt=\"UG尾巴.gif\" /></p>\n"}