【作者】某金融企业 徐佳燕 郑泽斌

目录

1. 说明

2. 项目概述

3. 分布式存储和传统存储路线分析对比

4. 分布式持久化存储系统

5. 常见的几种分布式持久化存储系统

6. 容器持久化存储

7. 主流分布式存储技术的对比分析与应用

8. 分布式存储的异常问题场景

9. 本方案选用分布式存储系统-XSKY

10. XX银行容器分布式存储系统架构设计

11. 存储解决方案的特性

12. XSKY解决方案的优势和价值

1. 说明

1.1 适用范围

本技术方案适用于XX银行金融的分布式持久化存储系统建设，金融监管的要求，存储作为核心基础架构设施，需要保证高稳定性和高安全性，需要对数据一致性、灾备和恢复有严格的要求。指导银行业务部署容器云分布式存储业务，建设分布式数据中心与新技术融合发展，并可供相关行业参考。

1.2 定义

本文分析了金融行业机构对于核心存储的需求、采用分布式存储方案的架构设计、网络设计，并介绍了部分业界主流分布式存储产品。

2. 项目概述

2.1 项目背景

随着以docker为代表的容器技术的发展，为应用的开发、测试、运维带来了巨大的便捷。容器技术不仅在互联网企业应用广泛，在传统银行业的IT中也发展迅速。很多银行都在建设以docker为容器技术支撑的PaaS平台，尝试一些新型应用的微服务框架和容器化改造。由于数据对于银行的重要性，不可避免的要解决容器的持久化数据存储问题。本文将结合XX银行在分布式持久化存储系统平台建设和运维过程中的实践案例，阐述容器分布式持久化存储的必要性和难点。

1、XX银行将所有业务系统进行容器化部署，容器云平台的数据存储采取了分布式持久化技术

2、存储场景涉及了高性能计算、云应用、数据存储和分析、以及数据边界隔离。

3、由于金融监管的要求，存储作为核心基础架构设施，需要保证高稳定性和高安全性，需要对数据一致性、灾备和恢复有严格的要求。

2.2 项目需求

银行金融行业的发展带来的巨大冲击和挑战，逼迫金融行业不得不考虑互联网金融业务和移动业务的发展，这又对技术平台和技术能力提出了新的要求和挑战。银行金融业务和移动业务要求对业务需求快速响应，甚至是小时、分钟级，这就要求能实现业务的敏捷响应、敏捷开发、持续集成、持续部署、持续改进，实现自动化的运维、容错、异常修复、弹性伸缩、灰度发布等能力，要支持这些能力，环境一致性要求、基础设施服务平台等要求需要满足，才能在激烈的竞争中生存下来。金融公司业务的发展趋势，恰如如逆水行舟，不进则退，不得不采用新的技术和平台。

A、容器正逐渐成为云上应用的标准部署单元，容器云平台需要解决分布式持久化存储的需求。

B、容器编排系统已成为趋势，在无状态的容器中，分布式存储系统需要适配不同的存储模式和规模。

C、分布式持久化存储系统根据不通的场景具备融合架构和分离架构的能力。

D、分布式持久化系统需要满足高效率的文件检索、高带宽的吞吐性能，高可靠的数据安全保障。

E、存储插件需要支持不同的后端存储。

F、分布式持久化存储系统需要结合容器云平台实现自动化功能，如弹性伸缩，隔离管理，还需要具备可视化监控。

2.3 现状分析

1.、XX银行将所有业务系统进行容器化部署，容器云平台的数据存储采取了分布式持久化技术

2、存储场景涉及了高性能计算、云应用、数据存储和分析、以及数据边界隔离。

3、由于金融监管的要求，存储作为核心基础架构设施，需要保证高稳定性和高安全性，需要对数据一致性、灾备和恢复有严格的要求。

4  目前XX银行也正处于技术更新换代变革的时代，传统依托于大小机的各种系统逐渐过渡到云端，X86架构逐渐成为趋势与主流，以各大银行为代表的金融行业开始逐渐采用虚拟化与云计算技术来构建IT系统，提升IT系统的资源利用率。

3. 分布式存储和传统存储路线分析对比

3.1架构对比

传统集中式存储一般采用集中式控制，并且在控制节点存储大量的元数据信息，从而使控制节点容易成为系统的瓶颈。对于分布式系统，如我们的ONEStor系统，节点可以通过cluster map（集群元数据）， 直接计算出数据的存储位置，从而对OSD（硬盘）进行直接读写，完全是分布式并行的；而其元数据，也就是cluster map，是轻量级数据，且其更新的频率相对而言也是较低的。这种架构就在理论上保证了ONEStor具备线性扩展能力。而且在缓存设计，节点数据迁移方式等方面同样满足线性扩展的要求。理论上，分布式存储集群的最大节点规模并没有严格限制；实践中，已经有超过百节点的部署应用。所以说无论从节点规模还是可扩展行上分布式架构有着天热的优势。

为了对数据存储获得高可靠性，常用的方法就是多副本技术，即把用户的数据在存储体中存放多份，比如典型的3副本。在这种情况下，只有在3份数据全部丢失，用户的数据才会真正丢失。而对分布式存储系统来说，由于其多节点的分布式架构，允许不同副本根据用户需求灵活配置存放规则，从而做的有效的数据隔离和保证最大的故障域，即使节点级别和机架级别的故障都不会对存储数据的正常访问造成影响。

3.2 性能对比

和传统集中式存储相比，分布式集群的读写数据最终会被分布算法打散，以概率均匀的方式分布到各节点和硬盘上，从而集群整体的IO和Throughput能力是各节点能力的总和。换句话说，也就是集群的性能随节点数量的增加而线性增加。

分布式存储集群的性能取决于两方面，一方面是单节点的能力，另一方面是系统的扩展能力。分布式系统的性能可以随节点的规模而线性扩展，所以对第二点来说，已经达到了最大化。对于单节点的能力，分布式系统设计和硬件配置方便实现了足够的灵活性，从而可以表现出良好的性能。

对传统的HDD来说，受寻道能力的限制，单盘的随机读写能力一般不超过200IOPS。SSD的出现，使得在IOPS上的能力相比于HDD有了大幅的提升，一般可以提升2个数量级以上，从在在当前对IOPS有较高需求的应用（如数据库、VDI等）中得到了广泛使用。另一方面，当前SSD在容量、价格、使用寿命等方面和HDD相比还有一定的差距，所以针对不同的场景和需求，一个良好的存储系统应该可以进行灵活的配置。举例来说：

ONEStor系统支持的硬盘类型包括：全HDD、SSD+HDD混合组网、全SSD。在SSD+HDD混合组网模式下，ONEStor系统既可以将SSD作为Cache使用，也可以将SSD和HDD放到不同的pool，做分层存储使用。在混合模式下，既可以发挥SSD 的IOPS和Throughput的优势，又可以发挥HDD的容量和价格优势，是目前广泛采用的存储架构。

3.3 应用场景

分布式存储系统和传统集中式系统相比，具有更好的扩展能力，所以更适合那些需要进行灵活扩展以满足快速变化的业务需求的场景、并确保数据可用及业务不中断。

分布式存储系统能够很好的平衡硬盘利用率，充分发挥集群的性能，可广泛应用于虚拟计算，虚拟桌面，云网盘，数据备份等需要高可靠性，高稳定性、高可用性后端存储的场景。

分布式存储推荐应用场景：

3.4 分布式存储灾备方案

分布式存储灾备方案和传统存储方案基本一致，也是采用远程数据复制方式进行数据备份，当主站点故障后，切换到备站点进行业务承载，分布式存储主备站点分别用两个集群部署，主站点采用3副本存储策略进行部署，备站点可以采用2副本或者纠删码策略进行部署，从而降低成本。

如图所示， 标注Onestor的框体代表Onestor集群，标注Client的框体代表客户业务运行的主机。左侧代表容灾主站点，右侧代表容灾备站点。框体中描述了该主机上运行的组件，其中黑体表示活跃，灰体表示备用。

ONEBack_Scheduler：部署在主用和备用集群的每个节点，用于调度备份恢复过程。

ONEBack_Backup：部署在主用和备用集群的每个节点，负责实际的备份工作。

ONEBack_Proxy：应用服务器运行于业务网段，容灾的调度任务运行于容灾网段，proxy进程用于跨网段的消息传递。

ONEBack_Agent：部署在应用服务器（目前支持数据库类型应用），负责在应用层做相应配合。

在H3C ONEStor分布式存储异地容灾系统中，上述组件采用全分布式设计。这样做的好处是：一方面不存在单点故障，单个节点或模块的失效不影响整个备份任务；另一方面，备份任务可以分布式并行处理，提升备份效率。

3.5 总体对比分析

4. 分布式持久化存储系统

分布式存储系统可以理解为多台单机存储系统的各司其职、协同合作，统一的对外提供存储的服务。所以无论是存储非结构化数据的分布式文件系统，存储结构化数据的分布式数据库，还是半结构化数据的分布式KV，在系统的设计上主要需要满足以下需求(但不仅限于)：基本读写功能、性能、可扩展性、可靠性、可用性。

4.1 有中心管理节点 AND 存储节点有主从

此种架构的系统以GFS为代表，以以下系统为例说明，整体设计和GFS类似，最近发现小米的分布式KV系统Pegasus用的是同样的架构设计方案。从基本的读写功能来说，分布式文件系统主要提供文件的读/写/删功能，那么从哪里读写？怎么读写？以什么形式存储？也就是在上篇所提到的数据定位和存储引擎的问题

在有中心控制节点的分布式文件系统，从哪里读写的任务基本是由中心控制节点完成的，即图中的Master节点。为了能完成这一项核心的任务，Master节点需要做两件比较重要的事情：

1.存储节点信息和状态

对于分布式文件系统，从文件到某一台单机上的一块磁盘的某个位置，会有一个逻辑的拓扑结构便于分区扩展或者数据隔离等等。拓扑结构从上至下存储池、分区、服务器、磁盘、文件目录等。

Master节点需要保存整个集群的全局视图，为了提高性能，这个逻辑拓扑结构一般会缓存在内存中，定期地持久化在Master节点的磁盘上

Master节点需要监听系统的所有数据节点和磁盘状态，如节点的上下线等，并对事件作出相应的处理来保证系统状态的正确性。

同时为了使得系统的数据分布和资源使用更均衡，Master节点可以获取数据节点的容量、负荷等状态，供读写调度模块有策略的去分配可写的资源。

文件读写的调度策略：

由于没有采用类似Hash算法这种静态计算读写位置的方式，中心控制节点就需要担任起调度的角色。当客户端发起写请求时，第一步会到Master节点获取文件ID，Master节点根据客户端读写文件的大小、备份数等参数以及当前系统节点的状态和权重，选择合适的节点和备份，返回给客户端一个文件ID，而这个文件ID包含了该文件多个副本位置信息。这样的好处是不用将每个文件的映射关系都存储下来。而对于对象存储系统因为功能的需要，这个对象和文件的映射关系是必需要保存的。

Master节点除了完成以上两种主要功能，还需承担维持副本数量和内容正确性的责任，因为毕竟它知道太多了，数据恢复调度的任务也是只能是它的，这里就先不展开了。

2. 存储节点选主

对于存储节点有主从之分的系统，每个备份的主从节点的选取也需要Master节点来控制。StorageNode数据节点除了负责文件在单机系统上如何进行存储，对于有主从之分的存储节点，各自还承担如何保持备份数据一致性的任务。归纳为以下几个要点：

1）.单机存储引擎的实现

主从存储节点在单机存储引擎的实现上几乎没有差异，解决的是文件如何存储的问题。对于不同的系统还有个区别是一个存储引擎负责一台机器所有磁盘的存储，还是一个磁盘一个存储引擎，我们这里以一个存储引擎负责一个磁盘的设计说明。

分布式文件系统的存储引擎大多都是在单机文件系统之上，数据最终以文件的形式存在。而单机文件系统以目录的形式将文件组织起来。该系统基本沿用了这一思想，是以目录为单位进行副本划分，而不是节点，和Swift一样称作为Partition，是备份的基本单位。以三备份为例，中心节点会根据策略选择三个不同的物理磁盘上创建同一个ID的Partition，在不同物理磁盘的同一个PartitionID下存储的文件是一样的。

这里还有另外一个问题，文件存储到单机文件系统上是否合并的问题。简单直接的做法，就是以一个个文件直接存储在指定的某个Partition目录下。这样的方式带来的问题也是直接可见的，直接受到文件系统随机读写的性能的制约，对于小文件读写比较多的场景来说，磁盘常常会成为整个系统的瓶颈，然后不得不通过增加节点来进行吞吐能力的扩展。

所以该系统将多个文件追加合并写在一个相对较大且大小固定的文件里，将随机写转为了顺序写，实验表明可以大大提高单机存储的吞吐能力。这样的解决方式带来的性能提升是明显，但是在实现上增加了一定的复杂性，合并必然就会带来定位文件的最终位置需要二次映射，即是在合并文件中的偏移。

2）.保证备份一致性

在保证备份一致性上，主从存储节点的角色就有一些区别了。对于Master节点选出的主存储节点，它需要根据主从一致性协议将数据推送到其它从节点，一般采用存储节点分主从的系统都会选择强一致协议，即主节点采用将数据发送给从节点收到响应成功后，才会将数据持久化到本地，返回用户成功，这样用户读到的数据始终是一致的。当然整个过程不是那么简单的，后续再一致性协议部分再展开。

3）.汇报消息，听从调度

对于存储节点需要保持和Master节点的心跳信息，同时将自己当前的容量和资源使用情况汇报给Master节点。从控制系统的角度来说，这才形成了一个负反馈系统。同时，存储节点处于待命状态，等待Master节点的派遣任务，比如说数据备份的恢复迁移等。

Client一般作为分布式文件系统的接入层，对写操作，接受用户数据流，将数据写入存储节点；对于读操作，从多副本中随机选择副本来读取。同时为了提高系统整体性能和可用性，该系统的Client一般还会负责额外的功能

集群信息缓存:主要为了减少与Master节点的交互，提高写的性能。可以从Master节点获取副本位置信息，缓存在本地，设置缓存过期时间。

异常处理：Client在提高系统可用性上扮演这重要的角色，在性能损耗可容忍的情况下，通过简单的重试超时方式即可解决Master、Storage节点不可用的异常，最大限度地保证系统可用性。

从性能角度来看，Master节点是不会成为系统瓶颈的，毕竟现在的服务器处理能力是很高的，无论是Master节点缓存的集群信息占用的内存，还是对于一个几万台机器的集群的调度，单机Master节点都是可以扛得住的。说道这里，在做系统性能测试时，对于分布式存储系统中的管理节点的性能，即管理流的场景要模拟覆盖到的。实验证明这样场景确实能发现了不少的性能问题。

那么对于有中心管理节点，数据节点有主从之分的系统，它的性能瓶颈是在哪里？根据理论分析，假设单机存储系统参数不当或代码实现导致的性能问题都已排除解决，即纵向的性能优化基本符合预期。这样一个系统，对于小文件的读写场景，在有限的磁盘数量和文件数量，如果数据分布的不是很分散，那么主要的性能瓶颈在于集群中某些磁盘的吞吐能力，而在大文件的读写场景，系统的瓶颈在主节点的出口网卡流量。以三备份为例，主节点需要往两个从节点写数据，这时候主节点的出口网卡流量是入口网卡的两倍，如果出口入口均为千兆网卡那么入口网卡的流量始终只能跑满到网卡最大流量的一半。所以在设计时才会以Partition为单位作为备份的基本单位，这样一来每个节点上面都有主从，每个节点的流量基本都可以跑满。

从可用性的角度来看，如果不做高可用的设计，Master节点就是系统的单点。消除系统单点的方法很多，一般分布式系统中常直接使用Zookeeper来保证节点的高可用。所以其实中心控制节点的单点问题并没有那么严重的。相比而言，中心控制节点的调度策略显得更为重要，因为数据分布的是否均衡直接影响到系统对外服务的性能。

4.2. 无中心管理节点 AND 存储节点无主从

以Swift为例说明，从其基本架构可以看出，Swift 采用了完全对称、所有组件都可以扩展的分布式系统架构设计，系统无单点存在。去掉Proxy-Server层对象映射的逻辑，可被看作为要讨论的分布式文件系统，从另一个角度Proxy-Server也可以看做是分布式文件系统的客户端，只是在实现上和对象存储的逻辑耦合相对比较紧密。

此外，对象存储逻辑层的认证服务、缓存服务忽略暂不讨论，Container-Server和Account-Server和Object-Server的设计基本一致，所以仅讨论Object-Server。

以下为Swift的基本架构图，包含主要各个组件：

Client

Swift的对象业务逻辑和底层的分布式文件系统耦合是比较近的，为了便于拆分理解，这里可以将Proxy-Server节点看做为分布式文件系统的Client端

抛开Proxy节点作为对象服务功能不谈，作为无中心控制节点系统Client端，它承担了比较重要的两个角色

1. 备份一致性的保证

Swift 采用Quorum 协议，关于此协议内容就不赘述了。Quorum协议对于一致性的保证很灵活。Swift默认选择的是写完三个备份才算写成功，也可通过配置参数选择写完2个副本即返回，剩余副本有Object-Replicator保证副本数量的正确性。对于读操作，Swift默认选择任意读其中一个备份数据即返回，此种弱一致性模型是很可能读到旧版本数据的，不过它支持用户在读操作请求头中增加 x-newest=true 参数来同时读取 2 个副本的元数据信息，然后比较时间戳来确定哪个是最新版本，返回给用户最新数据。

对于Swift选用的最终一致性模型实现，光靠Client数据流来保证是不可靠的，所以在StorageNode上会有进程定时检查备份是否一致，在Object-Replicator部分会说道。

2. 系统可靠性的保证

对于一个无中心的分布式文件系统来说，系统可靠性的保证不是某一个节点能全权负责的。Proxy节点主要是在处理用户数据流的时候最大程度的去保证用户请求能处理成功。但当用户发送一个上传对象的请求时，Proxy节点发现一个存储节点故障了，应该如何处理？

Swift引入了handoff节点，可理解为备用节点。其中，Swift的Ring对象的get_more_nodes方法，针对partition会返回一组handoff节点，如何挑选handoff节点先不展开，总体思想是尽量选择跟故障节点不在一个逻辑域和物理域，然后开始重试，重试次数由Proxy节点配置文件request_node_count 参数决定，默认是备份数的2倍。

StorageNode

Swift的StorageNode由以下几个组件组成。

Object Server，即单机的存储引擎实现，提供文件的元数据和内容存储。每个文件的的内容会以文件的形式存储在文件系统中，而元数据会作为文件属性来存储。每一个文件以生成的时间戳作为名字。

Object-Replicator，主要用于保证副本数量和位置的正确性以及一致性。在Swift的实际使用中，有几个场景都会导致副本的数量和位置不正确。先在这里简单举例，后面在说到数据恢复时会详细说明。如上文提到的临时写到handoff节点，Replicator会根据ring计算出的信息，把数据搬到正确位置，再如因为添加了磁盘或机器导致ring发生变化，再入Proxy节点配置了写亲缘性，Proxy节点会将数据优先写到某个分区，最后由Replicator把数据跨分区复制到正确的位置。在某些节点故障或者用户选择只写两备份就返回的场景下，副本会处于少备份的情况，这也是Replicator要做的事情。

Object-Replicator同时还会保证副本的一致性，以Partition/Suffix为基本单位(Suffix为Partition下的子目录)，以每个文件时间戳计算的hash值保存在Partition目录下的hashes.pkl文件中，通过请求远端备份的Object-Server获取hashes.pkl和本地值对比，发现不一致时会采用推的方式更新远程副本，使用远程文件拷贝工具 rsync 来做数据的同步，rsync带 ignore-existing参数，对于文件名相同的文件会忽略拷贝，这样就避免了全量拷贝。这样在远端备份同一个文件名的目录下可能会存储在不同版本的数据文件，这个Object-Server在处理读操作的时候会选择时间最新的数据返回。从这个角度来看，Object-Replicator对保证副本的一致性起到了作用。

Object-Auditor：主要用于检测副本数据是否正确，当发现比特级的错误，文件将被隔离，这样远程Object-Replicator检测到副本缺少时会将正确的副本推送过来。Object-Updater：主要是解决对象存储的元数据的更新问题，简要说明下，文件成功创建后会将对象名更新到Container-Server，当Object-Server由于高负载的原因而无法立即更新时，任务将会被保存到本地文件，以便服务恢复后进行异步更新；Updater服务主要就是负责系统恢复正常后扫描任务做相应的更新处理。

没有中心控制节点，所以Swift的可靠性的保证落在各个节点上，责任分工在上文也有所描述，这同时也需要每个节点都要拥有整个集群的配置信息，也就是Ring文件才能开展工作。所以，一旦Ring发生改变时候需要同步到集群的所有节点，否则系统就没法正常工作了。虽然对于Swift系统来说只有管理员在做节点增减等运维操作时候才会改变Ring结构，然后同步到各个节点，但是常常在生产使用中，还是最好是需要一个第三方监控进程，对比各个节点Ring文件的MD5，保证集群中所有节点的Ring文件始终保持一致.

从性能的角度来说，对于无中心管理节点，且数据节点业务主从之分的系统，同样也需要考虑集中典型的场景，来分别考虑其性能瓶颈。同样也需要假设单机存储系统参数不当或代码实现导致的性能问题都已排除解决，即纵向的性能优化基本满足需求。

5 常见的几种分布式持久化存储系统

5.1 XSKY分布式存储

星辰天合（北京）数据科技有限公司（XSKY）是专注于软件定义基础架构（Software Defined Infrastructure）业务的高新技术企业，提供企业级分布式软件定义存储产品，帮助客户实现数据中心架构革新。

XSKY推出X-EBS、X-EFS、X-EOS和X-EDP等产品，支撑了行业云、私有云、桌面云、数据库资源池、海量媒体数据、影像数据、智能制造数据等不同类型的应用场景。帮助用户降低整体拥有成本。XSKY的产品已在政府、金融、电信、广电、教育、医疗、能源、制造等不同领域得到客户充分认可。截至2017年Q3，XSKY已经向客户稳定交付超过100PB容量的产品。根据IDC《2017年Q2中国软件定义存储及超融合市场跟踪报告》显示：XSKY在2017年上半年保持了迅猛的市场发展势头，对象存储细分市场份额排名第一，块存储细分市场第二，而在中国SDS的整体排名中，XSKY位居前三。

5.1.1 XSKY 分布式块存储 X-EBS

X-EBS（XSKY Enterprise BlockStorage）产品是星辰天合提供的企业级分布式软件定义块存储解决方案，它基于主流的开源分布式存储系统Ceph，在性能方面进行了深度优化，对可靠性、易用性、可管理性进行了巨大改进，实现了7*24的自动化运维。X-EBS不但可支持运营商实现数十PB级以上容量的存储资源池，也可帮助企业实现成本可控的小规模水平扩展存储，整合或替代现有中端存储设施，或构建应用融合方案，支撑各种业务应用。

X-EBS分布式块存储产品架构图

以往的分布式存储解决方案仅仅解决了存储容量问题和扩展性问题。从很多应用场景适配度和成本的角度看，这些分布式存储解决方案往往不能够平滑地替代传统存储设备。而X-EBS作为新一代的分布式块存储产品，适用于更广泛的应用场景。

表1 X-EBS对比传统存储

简而言之，X-EBS分布式块存储产品可以帮助用户发挥通用的x86服务器硬件设施的性能潜力，在管理特性、效能和接口各方面达到传统SAN设备的水平，并具备水平扩展的能力，让用户在TCO可控的情况下轻松实现软件定义存储的目标。

5.1.2 XSKY分布式对象存储X-EOS

X-EOS（XSKY Enterprise Object Storage）产品是星辰天合提供的运营商级的对象存储解决方案，它基于主流的开源分布式存储系统Ceph，并集成了性能优化、可靠性、可管理性的巨大提升，实现了7*24的自动化运维。不但可帮助云计算运营商实现大规模云存储集群，传统企业也可基于它构建非结构化数据存储池，实现云原生基础架构的转型。

5.1.3统一存储：X-EDP产品介绍

X-EDP（XSKY Enterprise DataPlatform）是星辰天合提供的分布式统一数据存储平台产品，它是主流开源技术组件，企业主要工作负载整合优化，以及互联网自动化运维实践经验集成于一身的产品。X-EDP统一数据存储平台推出的目的是为用户能实现云原生的一站式存储资源池管理，简化数据保护设计，并能够全面发掘既有数据的潜在价值。

X-EDP 围绕云基础架构设计，通过存储系统软件将通用硬件的本地存储资源组织起来，构建全分布式存储池，不但可支持运营商实现数十PB级以上容量的存储资源池，也可帮助企业实现成本可控的小规模水平扩展存储，整合或替代现有中端存储设施，或构建应用融合方案，支撑各种业务应用。

X-EDP是一个真正的统一存储，实现了同一套存储系统向上层应用同时提供块、文件和对象三种数据服务，满足业务对结构化、半结构化、非结构化数据的存放需求。并且内置数据保护功能，例如：备份、复制、容灾、云分层等，同时X-EDP提供多种企业级特性，包括快照、精简配置、备份、加密、压缩、QoS等，帮助企业轻松应对业务快速变化时的信息灵活、可靠存取需求。

5.2 Ceph分布式存储

5.2.1 概述

Ceph是可靠的、可扩展的、统一的、分布式的存储系统。可以同时提供对象存储RADOSGW（Reliable、Autonomic、Distributed、Object Storage Gateway）、块存储RBD（Rados Block Device）、文件系统存储Ceph FS（Ceph Filesystem）3种功能。

5.2.2 Ceph应用场景

Ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；其块设备存储可以对接（IaaS），当前主流的IaaS运平台软件，如：OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。

（图源：51CTO博客）

5.2.3 Ceph核心组件

OSD（Object Storage Device）：主要功能包括存储数据、处理数据的复制、恢复、回补、平衡数据分布，并将一些相关数据提供给ceph monitor。例如ceph OSD心跳等。一个ceph存储集群，至少需要两个Ceph OSD来实现active+clean健康状态和有效的保存数据的双副本（默认情况下是双副本，可以调整）。注意：每一个disk、分区都可以成为一个OSD。

Monitor：Ceph的监控器，主要功能是维护整个集群健康状态，提供一致性的决策。

MDS（metadata Server）：主要保存的是Ceph文件系统的元数据。注意：ceph的块存储和ceph对象存储都不需要MDS。MDS为基于POSIX文件系统的用户提供了一些基础命令。

1）基础存储系统RADOS

RADOS：可靠自主分布式对象存储。它是ceph存储的基础，保证一切都以对象形式存储。

2）基础库LIBRADOS

LIBADOS：功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS进行应用开发。

5.3 Onestor分布式存储

5.3.1 软件架构

ONEStor存储软件采用全分布式的架构：硬件层、存储操作系统、分布式管理集群、基础服务、增值服务等模块组成，这种架构为存储系统的可靠性、可用性、自动运维、高性能等方面提供了有力保证。其系统架构组成如下图所示：

5.3.2 全分布式架构

ONEStor采用全分布式架构，在部署时，会把所有存储节点的本地硬盘组织成虚拟存储资源池，这样解决了传统存储体系结构存在容量、性能不易扩展的难题，同时对上层应用提供统一的块、文件、对象存储服务。

随着存储容量的增长，传统存储设备对性能和稳定性的要求越来越高，其自身的缺陷也逐渐暴露出来。传统存储为Scale up扩展方式，当存储容量或系统性能不够时，只能简单在同一机柜内添加硬盘或添加新的扩展柜。由于受到硬件信号传输距离限制，其扩展能力非常有限。分布式架构可以线性的扩展系统的容量及性能，并有效的解决了传统和集中式存储的各种限制和问题，其数据可以自动均衡的分布在各个存储节点上，元数据也可以分别存储在不同的元数据节点，同时提供良好的数据一致性保证。

ONEStor的分布式架构包括分布式管理集群、分布式哈希数据算法、分布式无状态客户端、分布式缓存等，为存储系统的可靠性、可用性、自动运维、高性能等方面提供了有力保证。

ONEStor的系统架构组成如下图所示:

上图中，ONEStor逻辑上可分为三部分：OSD、Monitor、Client。在实际部署中，这些逻辑组件可灵活部署，也就是说既可以部署在相同的物理服务器上，也可以根据性能和可靠性等方面的考虑，部署在不同的硬件设备上。下面对每一部分作一简要说明。

（1）OSD：Object-based Storage Device

OSD由系统部分和守护进程（OSD deamon）两部分组成。OSD系统部分可看作安装了操作系统和文件系统的计算机，其硬件部分包括处理器、内存、硬盘以及网卡等。守护进程即运行在内存中的程序。在实际应用中，通常将每块硬盘（SSD或HDD）对应一个OSD，并将其视为OSD的硬盘部分，其余处理器、内存、网卡等在多个OSD之间进行复用。ONEStor存储集群中的用户都保存在这些OSD中。OSD deamon负责完成OSD的所有逻辑功能，包括与monitor和其他OSD（事实上是其他OSD的deamon）通信以维护更新系统状态，与其他OSD共同完成数据的存储和维护，与client通信完成各种数据对象操作等等。

（2）Monitor

Monitor是集群监控节点。Monitor持有Cluster Map信息。所谓Cluster Map，粗略的说就是关于集群本身的逻辑状态和存储策略的数据表示。onEStor Cluster Map包括Monitor map、OSD map、pg map、crushmap等，这些map构成了集群的元数据。总之，可以认为Monitor持有存储集群的一些控制信息，并且这些map信息是轻量级的，只有在集群的物理设备（如主机、硬盘）和存储策略发生变化时map信息才发生改变。

（3）Client

这里的Client可以看出外部系统获取存储服务的网关设备。client通过与OSD或者Monitor的交互获取Cluster Map，然后直接在本地进行计算，得出数据的存储位置后，便直接与对应的OSD通信，完成数据的各种操作。在此过程中，客户端可以不依赖于任何元数据服务器，不进行任何查表操作，便完成数据访问流程。这一点正是ONEStor分布式存储系统可以实现扩展性的重要保证。

另外，ONEStor作为文件存储会新增MDS组件，主要功能如下：

（4）集群元数据服务（MDS）

元数据是定义数据的数据，主要是描述数据属性的信息，用来支持如指示存储位置、指示历史数据、查找资源、文件记录等功能。元数据存放在元数据池中（存储系统中一种虚拟化的存储空间）。

传统文件系统将元数据与数据保存在本地，如果元数据与数据中有任何一部分损坏都会造成文件不可读写，且不可恢复。

CAPFS分布式文件系统建立在由多个节点组成的集群上，将数据与元数据彻底分离。元数据存放在元数据池中，通过元数据服务进行管理；数据存放在数据池中，通过NAS服务器对外提供存取服务。此文件系统模型降低了服务器的负载，提升整个集群的性能。

存储集群元数据由元数据服务集群管理，元数据都集中存放在OSD上，元数据服务只用了处理元数据请求已经缓存部分元数据信息，元数据服务集群上缓存的元数据信息使用动态子树分割管理。在打开一个文件过程中元数据服务解析文件名，将其转换为文件元数据信息；如果文件存在且访问是合法的，则元数据服务将文件的元数据信息返回给客户端，元数据服务器也可以授予客户端一定的权限（指定哪些操作是合法的，用4个字节标明，包括读，缓存读，写，写缓冲区）。

CAPFS默认将集群内所有存储节点都作为MDS，其中处于主用状态的MDS数量为N/2（向下取整，N为MDS节点数量），剩余的节点作为备用MDS。

MDS节点的运行状态有主用、停止、备用、连接中、未响应和故障六种状态。

• 当监控节点长时间未收到MDS节点的心跳响应时，状态显示为未响应。

• 当MDS节点发生异常后，若存在其他可用的MDS节点，则该异常MDS节点的状态显示为停止；若MDS节点被管理员手动停止，则其状态显示为停止。

• 主用MDS节点发生异常或被管理员手动停止，接替其业务的备用MDS节点在执行主备切换的过程中，状态显示为连接中；MDS节点启动后在等待其他主用MDS节点加入的过程中，状态显示为连接中。

• 当MDS节点管理的元数据损坏且无法自动恢复时，状态显示为故障。

对于文件存储而言，ONEStor系统逻辑上可分为四部分：OSD（Object-based Storage Device，对象存储设备）、Monitor（监控服务）、Client（客户端）、MDS（metadata server，元数据服务）。

6 容器持久化存储

容器正逐渐成为云上应用的标准部署单元，容器该如何解决持久化存储的需求？容器编排系统已成当红炸子鸡，在无状态的容器中，存储系统面临哪些新的挑战？这些都是容器云往分布式存储发展时经常遇到的一些问题点。持久化存储系统可分为开源存储系统和商业存储系统。通常商业存储系统会由厂商解决所有问题，这里就不展开来叙述了。块存储、文件存储、对象存储三种存储访问方式不同的存储系统，最合适容器的，我想应该是对象存储系统，对象存储系统是通过 URL 访问的，应用程序只需要知道对象存储系统的 URL 就可以直接访问存储系统，这种方式更贴近容器的无状态、临时性和快速调度。

6.1 为什么选择分布式存储系统？

1、云计算时代，传统存储不能满足虚拟化、容器对存储的需求

传统存储缺少灵活性，虚拟机、容器的部署及其负载是快速变化的，并且容器还是快速迁移的。

传统存储缺少自动化

传统存储缺少细粒度控制

传统存储的配置是非常严格的

2、构建存储的 TCO( 总拥有成本 ) 十分高昂

数据量成指数级增长，但存储的预算却没有相应的增长，传统存储的价格是无法承受之痛。

数据规模快速增长，企业往往需要过度预算，过度采购，因为传统存储的扩展，升级和替换是十分昂贵的。

3、高昂的存储系统运营成本 (OPEX)

需要专业的存储管理团队，不仅需要学习专业的存储知识，还要学习存储厂商指定的技巧。

处理存储系统问题是相当花费时间。

6.2 容器定义存储(CDS)

随着现代数据中心的发展，新的应用形态(Cloud-native、DevOps、Micro Service等)都要求基于云平台构建(Cloud-native)，这对存储体系结构又有了新的要求，这些要求主要体现在以下几个方面。

面向服务的存储配置: 过去基于一个物理服务器或虚拟机配置存储卷的技术、依赖于FCoE、iSCSI等协议的技术已经落后了。

卷服务粒度更细、数量更多:在最现代化的服务模型中，如NoSQL和消息队列，通常被设计成大规模扩展方式。他们部署时需要存储支持更多卷数量、更小的卷容量。而不像过去，一个计算节点通常映射一个大容量卷来提供数据库等应用。

存储本地多层化: 目前服务器至少有两个存储层级。基于全球客户服务器采购的实际情况来看，数据中心的服务器来自不同的供应商的多种服务器，不同服务器具有不同的内部容量层。客户希望新的存储结构来理解这些变化和不同，并能自动利用不同存储提供存储服务。

存储超融合化: 新服务架构要求数据计算和存储融合。以Hadoop为例，在计算是派遣到服务节点上运行的主机数据。

在数据中心中，硬件结构的现状一般是，来自不同供应商的服务器各自为政，不同存储容量和不同类型的服务器并存，Top of Rack交换机的能力也不同，而运行其上的软件是以一个更高的粒度，通过松耦的一组容器化服务运行在不同节点上。那么，我们该如何扩展存储层来与大量相对较薄的服务一起工作呢，当然，常用的做法就是将堆栈拆分成独立的数据可用区和计算区，根据不同SAL的应用需求匹配相应的存储资源。

一个容器感知存储架构，该架构要实现如何根据存储需求将数据放置在容器的位置区。这种架构可以支撑一个更大的容器计算集群，同时可以保持存储的性能和时延要求。

面对更细粒度的、自恢复和可发现的面向服务的应用架构，存储也不应该有任何核心的集中元数据服务器，元数据应该分布式存放和去中心化存放，并通过负载均衡等算法或检测协议(Gossip Protocol)实现高效的故障自愈系统和高可靠系统。

6.3 容器存储的实现方式

（1）原生云存储方案：按照纯粹的原生云的设计模式，持久化数据并不是存储在容器中，而是作为后端服务，例如对象存储和数据库即服务。这个方案可以确保容器和它们的数据持久化支持服务松耦合，同时也不需要那些会限制扩展的依赖。

（2）把容器作为虚拟机：利用容器带来的便携性的优点，一些用户将容器作为轻量虚拟机来使用。如果便携性是迁移到容器的原因之一，那么采用容器替代虚拟机来安装遗留应用是这种便携性的反模式。由于存储数据是紧耦合在容器上，便携性难以实现。

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

6.4 容器持久化存储的问题和思考

（1）扩展性和弹性问题：在只有几十或几百容器的环境里，持久化存储实现架构可能并不会成为一个问题。但是一旦增长到成千上万的容器规模时，大量容器都是临时运行并且不断迁移，它们所依赖的持久化存储如果是紧耦合到特定容器宿主机的话将会极大地影响到整个容器架构的可扩展和弹性伸缩能力。试想一下构建一个大型云原生应用所使用的容器宿主机依赖于SAN存储来实现持久化，可扩展能力会被牢牢限制在可以连接到相同的SAN存储卷的服务器数量。或者使用共享文件系统来实现持久化，从一个容器挂载一个卷所需的时间通常要比新起一个容器更久一些。这就产生了一个容器里快速拉起一个应用的需求与挂载持久化存储层必需的耗时两者之间的相互冲突。

（2）行为模式：用户把应用从虚拟机迁移到了容器，为什么无法得到容器理应带来的全部收益。通过更多的持久化存储选择，是否已经偏离了像12要素这样的云原生应用的设计模式。传统的存储模式及解决方案的依赖可能恰恰是加深了对云原生设计的反模式。

（3）监控：容器持久化存储的实现往往要依赖于容器外部的数据存储，而对于磁盘IO要求比较高的应用会直接用宿主机的本地磁盘，容器内部只能看到持久化存储数据已用空间，并不能看到外部数据盘的大小。当容器数量不多并设置相应的规则可以监控外部数据盘，但当容器数量过多并用到了不同的外部存储卷，针对于单个容器精细化的持久化数据存储监控可能就会成为问题。

7 主流分布式存储技术的对比分析与应用

传统存储虽然有技术成熟、性能良好、可用性高等优点，但面对海量数据，其缺点也越来越明显：如扩展性差、成本高等。为了克服上述缺点，满足海量数据的存储需求，市场上出现了分布式存储技术。

分布式存储系统，通常包括主控服务器、存储服务器，以及多个客户端组成。其本质是将大量的文件，均匀分布到多个存储服务器上。当前，分布式存储有多种实现技术，如HDFS、Ceph、GFS、Switf等。在实际工作中，为了更好地引入分布式存储技术，我们需了解各种分布式存储技术的特点，以及各种技术的适用场景。

7.1 Ceph

Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表，并随后贡献给开源社区。经过多年的发展之后，已得到众多云计算和存储厂商的支持，成为应用最广泛的开源分布式存储平台。

Ceph根据场景可分为对象存储、块设备存储和文件存储。Ceph相比其它分布式存储技术，其优势点在于：它不单是存储，同时还充分利用了存储节点上的计算能力，在存储每一个数据时，都会通过计算得出该数据存储的位置，尽量将数据分布均衡。同时，由于采用了CRUSH、HASH等算法，使得它不存在传统的单点故障，且随着规模的扩大，性能并不会受到影响。

1.Ceph的主要架构

Ceph的最底层是RADOS（分布式对象存储系统），它具有可靠、智能、分布式等特性，实现高可靠、高可拓展、高性能、高自动化等功能，并最终存储用户数据。RADOS系统主要由两部分组成，分别是OSD和Monitor。

RADOS之上是LIBRADOS，LIBRADOS是一个库，它允许应用程序通过访问该库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。

基于LIBRADOS层开发的有三种接口，分别是RADOSGW、librbd和MDS。RADOSGW是一套基于当前流行的RESTFUL协议的网关，支持对象存储，兼容S3和Swift。librbd提供分布式的块存储设备接口，支持块存储。MDS提供兼容POSIX的文件系统，支持文件存储。

2.Ceph的功能模块

Ceph的核心组件包括Client客户端、MON监控服务、MDS元数据服务、OSD存储服务，各组件功能如下：

Client客户端：负责存储协议的接入，节点负载均衡。

MON监控服务：负责监控整个集群，维护集群的健康状态，维护展示集群状态的各种图表，如OSD Map、Monitor Map、PG Map和CRUSHMap。

MDS元数据服务：负责保存文件系统的元数据，管理目录结构。

OSD存储服务：主要功能是存储数据、复制数据、平衡数据、恢复数据，以及与其它OSD间进行心跳检查等。一般情况下一块硬盘对应一个OSD。

3.Ceph的资源划分

Ceph采用crush算法，在大规模集群下，实现数据的快速、准确存放，同时能够在硬件故障或扩展硬件设备时，做到尽可能小的数据迁移，其原理如下：

当用户要将数据存储到Ceph集群时，数据先被分割成多个object，(每个object一个object id，大小可设置，默认是4MB），object是Ceph存储的最小存储单元。

由于object的数量很多，为了有效减少了Object到OSD的索引表、降低元数据的复杂度，使得写入和读取更加灵活，引入了pg(PlacementGroup )：PG用来管理object，每个object通过Hash，映射到某个pg中，一个pg可以包含多个object。

Pg再通过CRUSH计算，映射到osd中。如果是三副本的，则每个pg都会映射到三个osd，保证了数据的冗余。

4.Ceph的数据写入

Ceph数据的写入流程

1.    数据通过负载均衡获得节点动态IP地址；

2.    通过块、文件、对象协议将文件传输到节点上；

3.    数据被分割成4M对象并取得对象ID；

4.    对象ID通过HASH算法被分配到不同的PG；

5.    不同的PG通过CRUSH算法被分配到不同的OSD

5.Ceph的特点

Ceph支持对象存储、块存储和文件存储服务，故称为统一存储。采用CRUSH算法，数据分布均衡，并行度高，不需要维护固定的元数据结构；数据具有强一致，确保所有副本写入完成才返回确认，适合读多写少场景；去中心化，MDS之间地位相同，无固定的中心节点。

Ceph存在一些缺点：

去中心化的分布式解决方案，需要提前做好规划设计，对技术团队的要求能力比较高。Ceph扩容时，由于其数据分布均衡的特性，会导致整个存储系统性能的下降。

7.2 GFS

GFS是google的分布式文件存储系统，是专为存储海量搜索数据而设计的，2003年提出，是闭源的分布式文件系统。适用于大量的顺序读取和顺序追加，如大文件的读写。注重大文件的持续稳定带宽，而不是单次读写的延迟。

1.GFS的主要架构

GFS 架构比较简单，一个 GFS 集群一般由一个 master 、多个chunkserver 和多个 clients 组成。

在 GFS 中，所有文件被切分成若干个 chunk，每个 chunk 拥有唯一不变的标识（在 chunk 创建时，由 master 负责分配），所有 chunk 都实际存储在 chunkserver 的磁盘上。

为了容灾，每个 chunk 都会被复制到多个chunkserver

2.GFS的功能模块

GFS client客户端：为应用提供API，与POSIX API类似。同时缓存从GFS master读取的元数据chunk信息；

GFS master元数据服务器：管理所有文件系统的元数据，包括命令空间（目录层级）、访问控制信息、文件到chunk的映射关系，chunk的位置等。同时 master 还管理系统范围内的各种活动，包括chunk 创建、复制、数据迁移、垃圾回收等；

GFS chunksever存储节点：用于所有 chunk的存储。一个文件被分割为多个大小固定的chunk（默认64M），每个chunk有全局唯一的chunkID。

3.GFS的写入流程

1. Client 向 master 询问要修改的 chunk在哪个 chunkserver上，以及 该chunk 其他副本的位置信息。

2. Master 将Primary、secondary的相关信息返回给 client。

3. Client 将数据推送给 primary 和 secondary；。

4. 当所有副本都确认收到数据后，client发送写请求给 primary，primary 给不同 client 的操作分配序号，保证操作顺序执行。

5. Primary 把写请求发送到 secondary，secondary 按照 primary 分配的序号顺序执行所有操作

6. 当 Secondary 执行完后回复 primary 执行结果。

7.    Primary 回复 client 执行结果。

由上述可见，GFS在进行写数据时，有如下特点：

GFS在数据读写时，数据流与控制流是分开的，并通过租约机制，在跨多个副本的数据写入中, 保障顺序一致性;

Master将chunk租约发放给其中一个副本，这个副本称为主副本，由主副本确定chunk的写入顺序，次副本则遵守这个顺序，这样就保障了全局顺序一致性；

Master返回客户端主副本和次副本的位置信息，客户端缓存这些信息以备将来使用，只有当主副本所在chunkserver不可用或返回租约过期了，客户端才需要再次联系Master；

GFS采用链式推送，以最大化利用每个机器的网络带宽，避免网络瓶颈和高延迟连接，最小化推送延迟；

GFS使用TCP流式传输数据，以最小化延迟。

7.3 HDFS

HDFS（Hadoop Distributed FileSystem），是一个适合运行在通用硬件(commodity hardware)上的分布式文件系统，是Hadoop的核心子项目，是基于流数据模式访问和处理超大文件的需求而开发的。该系统仿效了谷歌文件系统(GFS)，是GFS的一个简化和开源版本。

1.HDFS的主要架构

HDFS Client（客户端）：从NameNode获取文件的位置信息，再从DataNode读取或者写入数据。此外，client在数据存储时，负责文件的分割；

NameNode（元数据节点）：管理名称空间、数据块（Block）映射信息、配置副本策略、处理客户端读写请求；

DataNode（存储节点）：负责执行实际的读写操作，存储实际的数据块,同一个数据块会被存储在多个DataNode上；

Secondary NameNode：定期合并元数据，推送给NameNode，在紧急情况下，可辅助NameNode的HA恢复。

2.  HDFS的特点（Vs GFS）

分块更大，每个数据块默认128MB；不支持并发，同一时刻只允许一个写入者或追加者;过程一致性,写入数据的传输顺序与最终写入顺序一致;

Master HA，2.X版本支持两个NameNode，（分别处于Active和Standby状态），故障切换时间一般几十秒到数分钟。

3.HDFS适合的应用场景

适用于大文件、大数据处理，处理数据达到 GB、TB、甚至PB级别的数据。适合流式文件访问，一次写入，多次读取。文件一旦写入不能修改，只能追加。

4.HDFS不适合的场景

低延时数据访问。小文件存储并发写入、文件随机修改

7.4 Swift

Swift 最初是由Rackspace公司开发的分布式对象存储服务， 2010 年贡献给 OpenStack 开源社区。作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。

1.  Swift的主要架构

Swift 采用完全对称、面向资源的分布式系统架构设计，所有组件都可扩展，避免因单点失效而影响整个系统的可用性。

Swift 组件包括：

代理服务（Proxy Server）：对外提供对象服务 API，转发请求至相应的账户、容器或对象服务

认证服务（Authentication Server）：验证用户的身份信息，并获得一个访问令牌（Token）

缓存服务（Cache Server）：缓存令牌，账户和容器信息，但不会缓存对象本身的数据

账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务

容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务

对象服务（Object Server）：提供对象元数据和内容服务，每个对象会以文件存储在文件系统中

复制服务（Replicator）：检测本地副本和远程副本是否一致，采用推式（Push）更新远程副本

更新服务（Updater）：对象内容的更新

审计服务（Auditor）：检查对象、容器和账户的完整性，如果发现错误，文件将被隔离

账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象

2. Swift特点

原生的对象存储，不支持实时的文件读写、编辑功能

完全对称架构，无主节点，无单点故障，易于大规模扩展，性能容量线性增长

数据实现最终一致性，不需要所有副本写入即可返回，读取数据时需要进行数据副本的校验

是OpenStack的子项目之一，适合云环境的部署。

Swift的对象存储与Ceph提供的对象存储区别：客户端在访问对象存储系统服务时，Swift要求客户端必须访问Swift网关才能获得数据。而Ceph可以在每个存储节点上的OSD（对象存储设备）获取数据信息；在数据一致性方面，Swift的数据是最终一致，而Ceph是始终跨集群强一致性）

7.5 Lustre分布式存储

Lustre是基于Linux平台的开源集群（并行）文件系统，最早在1999年由皮特•布拉姆创建的集群文件系统公司（Cluster File Systems Inc.）开始研发，后由HP、Intel、Cluster File System和美国能源部联合开发，2003年正式开源，主要用于HPC超算领域。

1、Lustre的主要架构

Lustre组件包括：

管理服务器(MGS)：存放集群中所有Lustre文件系统的配置信息，Lustre客户通过联系MGS获取信息，可以与MDS共享存储空间

元数据服务器(MDS): 管理存储在MDT中的元数据，使存储在一个或多个MDT中的元数据可供Lustre客户端使用，每个MDS可管理一个或多个MDT。

元数据目标(MDT): MDS用于存储元数据(例如文件名，目录，权限和文件布局)，一个MDT可用于多个MDS，但一次只能有一个MDS访问

对象存储服务器(OSS)：为一个或多个本地OST提供文件I / O服务和网络请求处理, 通常，OSS服务于两个到八个OST

对象存储目标(OST)：用户文件数据存储在一个或多个对象中，每个对象位于单独OST中Lustre客户端：运行Lustre客户端软件的计算节点，可挂载Lustre文件系统。客户端软件包括一个管理客户端(MGC)，一个元数据客户端(MDC)和多个对象存储客户端(OSC)。每个OSC对应于文件系统中的一个OST。

逻辑对象卷(LOV)：通过聚合OSC以提供对所有OST的透明访问，逻辑元数据卷(LMV)通过聚合MDC提供一种对所有MDT透明的访问。

2、Lustre特点

支持数万个客户端系统，支持PB级存储容量，单个文件最大支持320TB容量支持RDMA网络，大文件读写分片优化，多个OSS能获得更高的聚合带宽缺少副本机制，存在单点故障。如果一个客户端或节点发生故障，存储在该节点上的数据在重新启动前将不可访问适用高性能计算HPC领域，适用于大文件连续读写。

7.6 主流分布式存储技术的比较

8 分布式存储的异常问题场景

对于一套分布式存储的方案，怎样评估它是好还是不好？

如何对分布式存储的不同实现进行分类？

分布式存储中的数据可靠性是如何计算的？

8.1 去中心化

任何一个分布式系统都需要中心化管理，因此所谓的去中心化，要点就在于中心点承担的职责大小，而这里面最主要的一个职责就是元数据的管理，而最主要的元数据莫过于数据和位置的映射关系。传统的中心点都需要维护数据和位置的映射关系，读写访问都需要经过中心点进行统一调度，中心点的性能瓶颈，可用性，可靠性，伸缩性等方面如何保障，都面临极大的挑战。而现在的去中心化，则无需维护数据和位置的映射，客户端通过算法计算即可获得相应映射关系，之后到相应节点直接进行访问即可，中心点职责被大幅减弱。由此可见，是否去中心化的一个重要标准为：是否维护数据和位置的映射关系。

去中心化后，无需维护数据和位置的映射关系，并不意味着没有了映射关系，而是采用算法固定了映射关系。同时，为了保证可靠性，一般还使用数据冗余技术，如副本（Replica），纠删码（EC）。算法本身则确保数据分布的均衡程度。但是，一旦节点发生增删（如扩容，故障），即用于算法计算的输入条件发生了变化，部分映射关系就发生了变化，即数据需要迁移。当然，迁移一般在系统内部自主完成，如Ceph所提供的自管理/自恢复特性。一般，去中心化的系统都会假定故障是一个常态化事件，这是就需要重点评估迁移效率以及造成的影响。比如Ceph在实际使用过程中，最难处理的部分就是数据迁移以及其带来的影响。

去中心化，一定程度上也意味着各自为政，需要统一管理的部分，比如统计分析，数据跟踪，权限控制，服务等级管理等，就变得比较复杂。在数据迁移方面，中心化因为有统一管理的信息，只需恢复故障部分的数据即可，而去中心化的系统，由于映射关系的变化，将导致一些非故障数据也可能需要迁移。比如将集群规模扩大一倍，为了重均衡，理论上就有一半数据需要迁移，而中心化系统就没有此类问题。

8.2 存储的业务需求

目前，流行的存储业务需求主要可归类成三种：

块存储：Block Storage，提供Linux的块设备接口，Qemu的块驱动接口，云硬盘接口等，实际使用时，性能方面重点关注的是时延

对象存储：Object Storage，提供键值（Key-Value）接口，如GET，PUT，DEL等，案例如Swift，S3等，性能方面重点关注吞吐量

文件存储：File Storage，提供POSIX文件系统或自定义的文件系统服务，支持目录及文件属性等功能，案例如GFS，HDFS，CephFS等

存储业务的性能需求，一般可通过数据的冷热，快慢，大小进行考虑，不同业务通常都对应不同的性能要求。通常，一个系统都只满足其中的一项需求，这也是类Unix系统的一个基本设计理念：如何使用和组合由用户自行完成，当然，这也带来了一定的运维成本。有些分布式存储，则提供多种，比如Ceph，同时提供这三种服务。Ceph架构中最核心的部件实际只有一个：RADOS，一切对象化，然后对上提供各类服务的接口。这也是Ceph所提的统一存储的概念。这一定程度上也满足了类Unix的设计理念。当然，实际应用中，同时需要使用多种业务的场景可能不见得有太多，而且Ceph本身还没完全适应生产环境，这也是目前专用系统依然使用比较广泛的原因之一。

8.3 数据保护

分布式系统都是由多个节点组成的，规模越大，异常状况越可能发生，比如网络异常，硬盘故障，宕机等。为了保证系统的可靠性和可用性，分布式系统必须使用副本来提高可用性，以降低异常状况带来的影响。当然，其中的读写过程都是在分布式系统内部完成的，对用户透明。但是，这也带来了新的问题：多个副本之间的一致性问题。最简单的策略是：写时要求全部副本写完才返回，读则随意读取一份即可。当写比较多时，这种方式将导致响应时间极大增加，更极端的情况，如果此时某个副本节点异常了，等待可能就是无限期的，可用性问题依然存在。

8.4 数据监测

怎么合理判断故障发生了，更是重要。常见的故障包括系统宕机，硬盘故障，网络异常等，其中网络异常的判断尤为困难，丢包或短时间内的网络异常，是常见的情况。简单粗暴的判断此类网络异常为故障，将可能导致系统内数据迁移不断发生，并最终影响整系统的可用性。一般情况下，会设置一些监测节点，用于收集节点相关信息，其中就包括节点的健康状态，该过程称为心跳检测。

8.5 问题场景小结

可靠性：数据不能丢失，这是所有存储系统的第一要务。理论上，数据丢失的概率始终是存在的，故系统需具备容错能力，以应对各种故障问题，尽可能降低数据丢失的风险

可用性：在规定时间内持续提供服务，容错能力是保证该特性的主要技术手段，性能要求方面可采用多节点等方案来提高

一致性：总能访问到最新数据。由于多节点的存在，数据副本之间如何保持一致就是个问题。可以看到，一致性和可用性这两个目标是存在冲突的

伸缩性：也称为扩展性，主要指增减节点的难易程度，通常指的是扩容的情况

性能：可认为是可用性的一个要求，如果系统无法提供相当的性能，则可视为不满足可用性要求

9 本方案选用分布式存储系统-XSKY

9.1 公司简介

星辰天合（北京）数据科技有限公司（XSKY）是专注于软件定义基础架构（Software DefinedInfrastructure）业务的高新技术企业，提供企业级分布式软件定义存储产品，帮助客户实现数据中心架构革新。

XSKY推出X-EBS、X-EFS、X-EOS和X-EDP等产品，支撑了行业云、私有云、桌面云、数据库资源池、海量媒体数据、影像数据、智能制造数据等不同类型的应用场景。帮助用户降低整体拥有成本。XSKY的产品已在政府、金融、电信、广电、教育、医疗、能源、制造等不同领域得到客户充分认可。截至2017年Q3，XSKY已经向客户稳定交付超过100PB容量的产品。根据IDC《2017年Q2中国软件定义存储及超融合市场跟踪报告》显示：XSKY在2017年上半年保持了迅猛的市场发展势头，对象存储细分市场份额排名第一，块存储细分市场第二，而在中国SDS的整体排名中，XSKY位居前三。

在未来，XSKY将继续携手产业链上下游合作伙伴，构建完善的SDS生态系统，通过高度的产品化，解决用户在混合云时代数据的管理、存放、读取、保护、流动等数据基础设施的关键问题。

9.2 架构发展

众所周知，容器架构的发展可以追溯到1979年，Unix操作系统Chroot模块为每个进程提供一套隔离化磁盘空间，开启了容器技术的先河；2006年谷歌开发出一个基于Linux系统的功能模块Process Container进程容器，被视为Docker容器的技术原型，2008年Process Container技术进一步发展成为LXC（Linux Container），在容器管理方面更为成熟。

针对银行用户对容器持久化存储的这一需求，XSKY作为国内专业存储厂商，首家通过了CSI认证，支持动态创建持久化卷；并同时支持不同类型应用的存储访问需求（RBD/NFS/iSCSI），包括容器镜像库如 Harbor 的对象存储需求；进而稳定对接多种容器编排系统，达到生产交付级别；提供丰富的存储高级特性，满足企业用户核心业务的多种数据容灾需求。

10 XX银行容器分布式存储系统架构设计

10.1 分布式技术选型路线

10.1.1 Openstack技术路线

Openstack无疑是最具影响力、最受业界所推崇和认可的云平台，它已经成为事实上的IaaS云平台标准。Openstack 具有如下特点：

OpenStack逻辑组件关系图

1）具有很强的灵活性，能快速组建云平台的标准服务。模块化的设计能够容易整合第三方的技术来满足商业需求，强大的伸缩性使得Openstack几乎可以构建目前可预见最大规模的云，Openstack的宗旨是为用户提供普适的开源云平台，不论是公有云、私有云，也不论云的规模大小，都可以基于Openstack构建易于部署且灵活扩展的基础架构。具备高可用性和单组件扩展能力，可集中部署，也可分布式部署。

2）面向开放架构的接口服务设计，不同子系统/组件之间以API调用，实现低耦合。可灵活的功能扩展，并可以灵活调整具体接口实现。具备极强的被集成能力，用户可以通过API实现自身应用的定制开发，甚至基于API调用可以对Openstack功能模块进行替换开发。

云操作系统是基于业界最主流、最受欢迎的OpenStack平台开发，针对OpenStack Nova（计算）、Cinder（块存储）、Swift（对象存储）、Neutron（网络）、Glance（镜像）等核心组件进行大量深度地优化和开发。同时，融入对客户需求的深刻理解，赋予云平台更多贴合用户需求的功能，为用户带来更好的云计算体验。

云操作系统架构图

10.1.2 KVM技术路线

KVM是Kernel-based Virtual Machine的缩写，致力于与内核本身进行深度集成，完全可以重用Linux内核中已经完善的进程调度、内存管理、I/O管理等代码。XEN也免费开源，但它归Citrix所有。Xen 支持所需的内核源代码补丁仅提供给特定的内核版本，这阻止了 Xen 虚拟化环境利用仅在其他内核版本中可用的新驱动程序、子系统及内核修复和增强。KVM 在 Linux 内核中的集成使它能够自动利用新 Linux 内核版本中的任何改进。

技术构架先进：天生支持硬件辅助虚拟化技术，也是第一个使用硬件辅助虚拟化的产品。商业虚拟化和XEN因为需要向前兼容，正所谓船大掉头难，他们有历史包袱，所以具有后发优势的KVM，架构上反而更优。

KVM性能完胜XEN：以裸机作为虚拟服务器测试的基准设备，同时在三台服务器上运行Phoronix性能测试套件；结论：KVM在十一项测试中有9项性能损耗在2%以内，其他2项在2%以上；Xen则在十一项测试中有3项损耗在2%以内，而其他几项损耗都在5-7%之间。总共十一个测试项，KVM vs Xen 11：0完胜、（第三方的测试报告：http://www.phoronix.com/scan.php?page=article&item=ubuntu_1110_xenkvm&num=1）

KVM安全性高于XEN：Xen 要求在物理虚拟机服务器上运行一个特殊配置的 Linux 内核，以用作在该服务器上运行的所有虚拟机的管理域，该内核的安全漏洞会导致所有虚拟机全部被攻破，去年连续暴露的XEN高危漏洞xsa-105，xsa-106以及xsa-107，均是可以攻击通过XEN平台到虚拟机Guest OS。XEN又再次发布了6个高危漏洞，其中包括可以直接对非法用户提权以获取系统管理权限的致命漏洞，而绝大部分国内虚拟化厂家并未对上述安全漏洞处理（仅阿里公布处理方案，其它基于XEN厂家未见提供补丁和升级措施）。同时，XEN因为不在Linux内核中，无法做到热补丁，必须重启修复。而KVM可以利用Linux内核的热补丁修复技术，直接替换问题代码，实现业务无中断的在线修复。Linux的补丁可直接解决KVM安全漏洞，而XEN是单独程序，和Linux补丁无关，需单独修复。XEN因为存在Ring0的虚拟机来接管所有Guest OS的IO，存在宿主机和虚拟机。

10.1.3 Ceph技术路线

Ceph已成为OpenStack上最通用的存储之一，也是是目前人气最高的开源存储项目之一。

Ceph系统的层次结构

Ceph存储系统逻辑层次结构图

自下向上，可以将Ceph系统分为四个层次：

（1）基础存储系统RADOS（Reliable, Autonomic, DistributedObject Store，即可靠的、自动化的、分布式的对象存储）

顾名思义，这一层本身就是一个完整的对象存储系统，所有存储在Ceph系统中的用户数据事实上最终都是由这一层来存储的。而Ceph的高可靠、高可扩展、高性能、高自动化等等特性本质上也是由这一层所提供的。因此，理解RADOS是理解Ceph的基础与关键。

物理上，RADOS由大量的存储设备节点组层，每个节点拥有自己的硬件资源（CPU、内存、硬盘、网络），并运行着操作系统和文件系统。

（2）基础库librados

这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是整个Ceph）进行应用开发。

RADOS采用C++开发，所提供的原生librados API包括C和C++两种。物理上，librados和基于其上开发的应用位于同一台机器，因而也被称为本地API。应用调用本机上的librados API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

（3）高层应用接口

这一层包括了三个部分：RADOS GW（RADOS Gateway）、 RBD（ReliableBlock Device）和Ceph FS（Ceph FileSystem），其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

其中，RADOS GW是一个提供与Amazon S3和Swift兼容的RESTfulAPI的gateway，以供相应的对象存储应用开发使用。

RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。目前，Red Hat已经将RBD驱动集成在KVM/QEMU中，以提高虚拟机访问性能。

Ceph FS是一个POSIX兼容的分布式文件系统。

（4）应用层

这一层是不同场景下对于Ceph各个应用接口的各种应用方式，例如基于librados直接开发的对象存储应用，基于RADOS GW开发的对象存储应用，基于RBD实现的云硬盘等等。

Swift提供的API功能主要包括：

• 用户管理操作：用户认证、获取账户信息、列出容器列表等；

• 容器管理操作：创建/删除容器、读取容器信息、列出容器内对象列表等；

• 对象管理操作：对象的写入、读取、复制、更新、删除、访问许可设置、元数据读取或更新等。

10.2 系统架构设计原则

作为银行用户，我们关注存储其实更多的是关注数据持久化存储，数据是核心资产，重要数据必须持久化存储并备份，需要遵循以下的一些设计原则：

1.从业务角度，应用运行时异常，状态、数据等存储起来用于恢复或重试执行。

2.日志数据是业务跟踪、查询、统计、分析等的重要基础，所有的操作都要基于数据的持久化存储。

3.容器弹性伸缩特性非常切合微服务扩缩需求，日志、运行时数据、结果等跟随容器迁移且不随容器销毁而消失。

4.Kafka、mysql等需要持久化的存储支持来部署并保存数据。

5.数据量累积，会带来质变影响。

6.大数据业务、AI业务等基于容器云的部署需求。

10.3 系统总体架构

10.3.1 系统架构

XSKY软件逻辑架构如下图所示

XSKY 块部署架构如下图所示：

• XMS-a是指Controller Master Agent，负责给GUI提供后台数据。

• XMS-s是提供GUI、API等管理功能，作为管理服务器来提供分布式存储集群的管理功能。 为保证集群管理功能高可用，建议至少设置并开启3个（即2n+1）XMS-s服务 ，并且保证至少一半（不含）以上（即n+1）的XMS-s服务可用。

• MON是指用于提供集群存储数据的监控服务。为保证集群数据监控功能高可用，建议至少设置并开启3个（即2n+1）MON服务，并且保证至少一半（不含）以上（即n+1）的MON服务可用。

• XDC（XSKY Data Client）是指给客户端提供数据访问的接口，支持iSCSI、FC和SCSI等不同类型的访问路径网关。

• RGW是对象存储网关，提供S3、NFS访问接口。

• OSD是指负责数据落盘的一个进程，副本和EC也通过OSD服务实现。每一个硬盘有一个OSD进程，所以本系统中统一把添加OSD服务的物理盘称作硬盘。

10.3.2 分布式网关层

XSKY 分布式网关层提供块、对象和文件接口，所有的接口都通过无状态网关（XDC、RGW）对外提供，支撑无障碍横向扩展。单个服务器上软件机头只占用较少的CPU资源，提供比集中式机头更高的IOPS。

通过存储服务层提供的多链路MPIO技术，XSKY的块设备网关实现多达4条链路的冗余，在出现三条链路故障的情况下仍旧保证业务能正常进行。

10.3.3 存储服务层

存储服务层在存储引擎之上为用户提供了丰富的存储功能：

资源管理方面，提供了多资源池管理、各种数据策略（副本、EC以及域的保护和隔离功能）以及卷Qos等功能；

高级存储功能方面，提供了精简配置、实时快照、链接克隆、远程备份以及数据链路高可用（MPIO）；

性能方面，XSKY自研了多级智能Cache技术。

XSKY支持将服务器SSD卡或SSD盘用作读、写缓存，对于数据的写操作，系统数据首先写到SSD的写缓存中，所有副本写缓存成功后，IO立即返回。

数据缓存均匀分布到各个节点上，所有服务器的缓存总容量远大于采用外置独立存储的方案。即使采用大容量低成本的SATA硬盘，XSKY仍然可以发挥很高的IO性能，整体性能提升3~5倍，同时提供更大的有效容量。

XSKY支持PCIe SSD卡或SSD盘用作数据缓存，除具备通常的写缓存外，增加热点数据统计和缓存功能，加上其大容量的优势，进一步提升了系统性能。

此外，XSKY 还提供Read RAM Cache，对业务IO模型进行智能识别，将数据预先读取到RAM Cache中，降低对磁盘的访问频次，同时提升系统读性能。Read RAMCache与W/R SSD Cache 一同构成多级Cache，提升系统的读写性能。

• Writecache机制

OSD在收到XDC发送的写IO操作时，会将写IO缓存在SSD cache后完成本节点写操作。同时，OSD会周期将缓存在SSD cache中的写IO数据批量写入到硬盘，周期未到之前若超过预定水位也会写入硬盘。

• Readcache机制

XSKY的读缓存采用分层机制，第一层为内存cache，内存cache采用LRU机制缓存数据，第二层为SSD cache，SSD cache采用热点读机制，系统会统计每个读取的数据，并统计热点访问因子，当达到阈值时，系统会自动缓存数据到SSD中，同时会将长时间未被访问的数据移出SSD。

OSD在收到XDC发送的读IO操作时，会进行如下步骤处理：

Step 1：从内存读cache中查找是否存在所需IO数据，如果存在，则直接返回，同时调整该IO数据到读cacheLRU队首，否则执行Step 2；

Step 2：从SSD的读cache中查找是否存在所需IO数据，如果存在，则直接返回，同时增加该IO数据的热点访问因子，否则执行Step 3；

Step 3：从SSD的写cache中查找是否存在所需IO数据，如果存在，则直接返回，同时增加该IO数据的热点访问因子；如果热点访问因子达到阈值，则会被缓存在SSD的读cache中。如果不存在，执行Step 4；

Step 4：从硬盘中查找到所需IO数据并返回，同时增加该IO数据的热点访问因子，如果热点访问因子达到阈值，则会被缓存在SSD的读cache中。

10.3.4 存储引擎层

传统数据分布策略采用一致性哈希(DHT)算法决定数据分布的策略，其将整个存储空间划分成虚拟的 N 个部分，然后将这些虚拟节点平均分给 M 个物理节点。一致性哈希部分解决了扩容导致的毁灭性数据迁移问题。但是随着集群几何级增加导致的数据不均衡问题仍然存在。

XSKY 采用CEPH技术作为框架，在Ceph RADOS的基础上实现存储引擎。Ceph使用的 CRUSH 算法通过增加多维参数来解决原来的一致性哈希问题。简单而言，CRUSH 算法在原来的哈希算法之上增加了物理部署逻辑和集群状态参数，使得在发生集群数据迁移变化时，根据物理部署情况最小化数据迁移量。比如根据输入的物理逻辑拓扑，CRUSH可以选择性地进行主机内部迁移，或着同一个机架/核心交换机迁移，大大减小了迁移造成的资源损耗。同时根据集群状态进行数据分布，能够充分兼容不同的存储设备。

10.3.5 硬件设备层

XSKY 分布式存储软件以通用的X86服务器为基础硬件平台：

• 硬盘方面：兼容各类SSD、SAS以及SATA硬盘，包括PCIe SSD；

• 网络访问：兼容主流千兆、万兆网卡、交换机，以及Inifiband 设备；

• 接口方面：兼容主流网卡和Qlogic 2672 16GB光纤卡。

10.4 方案规划设计

10.5 系统部署方案

10.5.1 组网方案

10.5.2 网络流量设计

网络存储平面，主要包括如下几个方面的网络流量：

• 业务流量

由于实际应用流量目前还不明确，暂时按照标书要求，单存储节点8K读IOPS为20000来评估业务流量（VMware虚拟化场景、数据库场景都主要是8KB流量）。

网络流量的计算公式为：块大小*IOPS。

业务最大流量为9.4GB =8KB*20000*60。

• 存储和重构流量

由于所有存储节点都连接在两台//万兆交换机下，数据重构时不会跨交换机重建，则交换机上行端口不需要考虑重构流量。

从整个流量计算来看，建议//每台交换机上行预留10个10GE端口用来完成与业务的对接。

10.6 软硬件配置清单

10.6.1软件配置清单

10.6.2 硬件配置清单

11 存储解决方案的特性

11.1 XSKY高级功能特性

• 统一块接口：块、对象和文件

XSKY真正实现了统一存储功能，提供块、对象以及文件接口。

XSKY的分布式网关层提供两种网关类型：

• 分布式块网关：可以提供SCSI、iSCSI、FC以及librbd的块接口。对于SCSI协议支持完整的SCSI-3协议栈，兼容HANA、MSCS等集群。

• 分布式对象网关：提供S3以及NFS接口。

• 企业级文件存储网关：提供NFS、CIFS、FTP等标准文件存储接口

分布式块存储网关和对象网关都是无状态网关，横向扩展不受限制，可以随着集群规模的扩展近似线性的提升IOPS性能。企业级文件存储网关是activ-standby主备模式，同一文件夹只可有1个路径访问，单文件夹性能会有瓶颈。

• 对于iSCSI接口，支持CHAP身份验证以保证客户端的访问是可信与安全的。CHAP全称是PPP询问握手认证协议（Challenge HandshakeAuthentication Protocol）。该协议可通过三次握手周期性的校验对端的身份，可在初始链路建立时以及链路建立之后重复进行。通过递增改变的标识符和可变的询问值，可防止来自端点的重放攻击，限制暴露于单个攻击的时间。

• 对于FC接口，XSKY 支持Qlogic 2672 16GB target Fiber Channel卡。将通用服务器转换成分布式FC-SAN。

• Librbd块接口，XSKY 通过XDC提供librbd 接口，相比于ceph本身提供的rbd接口，XSKY提供librbdproxy功能，优化librbd的效能，性能提升20%以上，资源消耗降低40%。

• 对象接口：XSKY 提供S3对象接口

• NFS 接口：XSKY 提供NFS、CIFS、FTP文件访问接口

• MPIO数据高可用

XSKY为iSCSI、FC传统企业接口设计了MPIO功能，提升数据链路可用性，当其中一条路径发生故障时，数据自动切换到另一条路径上（Failover），链路恢复时自动切换回来（Failback），切换过程中业务不感知存储的但路径故障。

从2.3版本开始，提供4条MPIO冗余路径，大大提升系统可靠性。

• 精简配置

XSKY提供了精简配置功能，为应用提供比实际物理存储更多的虚拟存储资源。相比直接分配物理存储资源，可以显著提高存储空间利用率。

采用CRUSH数据路由技术，系统无需使用专门的集中元数据来记录卷的精简分配情况，和传统SAN相比，不会带来性能下降。

• 快照

XSKY提供了快照机制，将用户的卷数据在某个时间点的状态保存下来，后续可以作为导出数据、恢复数据之用。XSKY快照数据在存储时采用ROW（Redirect-On-Write）写时重定向机制，更新源数据卷中的原始数据时，将源数据卷数据指针表中的被更新原始数据指针重定向到新的存储空间。单卷连续64个快照性能基本无损，快照数最大支持256个。

• 链接克隆

XSKY提供链接克隆机制，支持基于一个卷快照创建出多个克隆卷，各个克隆卷刚创建出来时的数据内容与卷快照中的数据内容一致，后续对于克隆卷的修改不会影响到原始的快照和其他克隆卷。

克隆卷继承普通卷所有功能：克隆卷可支持创建快照、从快照恢复以及再次作为母卷进行克隆操作。

XSKY 链接克隆

• 支持VAAI接口

XSKY遵循VMWare制定的存储卸载机制，实现了以下的API保证VMWare有更高的运行性能：

• Copy offload

Copyoffload 也被称作Full Copy 或Clone Blocks。当虚拟机克隆或根据模板创建虚拟机时，涉及到大量数据块的拷贝。通过Copy offload，不需要在ESXi服务器端进行拷贝，而是在存储端离线进行，从而降低ESXi服务器端资源开销。也可用在存储vMotion场景。

Copyoffload 示意图

• BlockZeroing

创建虚拟机时对虚拟磁盘立即清零是比较安全的，且后续使用性能没有性能下降。通过Block Zeroing 大大减少ESX主机与存储设备间的交互。

BlockZeroing 示意图

• Automatic Test and Set(ATS)

VMFS文件系统允许多主机对同一共享逻辑卷的并发访问，这是vMotion运行的必要条件。VMFS有一个内置的安全机制，防止虚拟机被超过一台的主机同时运行或修改。vSphere采用SCSI预留作为其传统文件锁定机制，这种方式在某项存储相关的指令操作期间，比如增量快照增长或发生时，均使用RESERVE SCSI命令锁定整个逻辑卷。这有助于防止冲突，不过也拖延了存储工作的完成，因为主机必须等待逻辑卷的解锁命令RELEASE SCSI才能继续写入。使用Atomic Test and Set(ATS)命令是一种硬件辅助的锁定机制，可以离线地对存储阵列加锁，这样就可以对个别磁盘数据块而非整个逻辑卷锁定。这样可以使得余下的逻辑卷在锁定期间继续被主机访问，十分有助于避免性能下降。该功能同时通过VMFS 数据存储，允许同一集群中部署更多的主机，以及更多的虚拟主机部署在同一个逻辑卷上。

AutomaticTest and Set 示意图

• UNMAP/Reclaimcommand

VMFS是文件系统，而下层为块。当删除或迁移虚拟机后，VMFS端看空间大，而下层未做实际的空间回收。当存储层提供API供VMFS调用，ESXi通过该接口通知下层回收空间。下层实现接口后，当虚拟机从一个DataStore迁走或删除立即调用该接口，阵列上的空间立即被回收。

UNMAP示意图

• 多资源池

为了满足使用不同性能存储介质以及故障隔离，XSKY支持多资源池特性。不同的资源池可以提供不同的性能以及不同的副本策略：

• 卷Qos

XSKY为卷设计了Qos功能，支持在线设置最大IOPS、突发IOPS、最大带宽、突发带宽，保证核心业务的优先策略。

技术上，XSKY采用漏桶与令牌桶相结合的IO流管理策略：

突发IO，会将在漏桶水位以内的IO优先处理（类似令牌桶积累一定令牌的情况），然后占用一定水位，通过计算Δt时间来释放水位。

漏桶无上限，一直放漏桶pending队列，不丢包。

支持允许突发(max)和不突发(avg)两种场景。不允许情况下超过avg的IO都需要epool中排队，允许突发情况下，超过avg的IO可以直接下发，突发情况下IOPS可以超过avg。

• Recovery Qos

当集群硬件异常时，或者进行硬件更换维护时，分布式存储进入recovery 状态，将失效硬件上的数据重新分布在其他节点，此时将产生RecoveryIO，如下图所示，当Server3异常离线时，Server1和Server2的PG除了处理业务IO之外，还需要处理RecoveryIO，此时，如果不进行控制，应用层发起的业务IO将会受到很大的冲击。XSKY Recovery Qos能对Recovery IO进行控制，并制定策略，根据用户需求保证业务IO或Recovery IO正常进行。

在存储池的范围内设置Recovery QoS，根据不同的业务类型设置不同的策略：

• 静态设置QoS，限制最大带宽。

• 动态设置QoS，系统动态的调整带宽。

• 海量小文件合并技术

XSKY 提供小文件合并归档功能，能将小文件合并成大文件再存储到系统中，能从容面对海量小文件（每日千万个文件出入）存储需求：

• 配置存储策略，小对象存入高性能副本存储池，大对象存入EC存储池

• 配置存储策略，开启合并归档功能

• 后台自动启动小对象合并归档任务，将存放在高性能副本池中的小对象合并成大对象后存入EC存储池

• 池级扩容及休眠技术

XSKY提供了按存储池扩容技术，以及冷池休眠技术：

• 数据通过压缩处理，大幅降低存储空间消耗

• 配置存储策略，选择EC存储资源池存放数据，大幅提高存储空间利用率

• 存储资源池存储空间不足时，创建一个新的存储资源池，将新的资源池激活成活动资源池，按资源池粒度扩容

• 非活动资源池可进入休眠状态，大幅降低电力、制冷成本

• 进入休眠状态的资源池，在有数据需要访问时能够快速响应

• 数据生命周期管理

存储桶数据生命周期管理支持，可以对存储桶内的数据通过数据前缀或整桶进行归档和删除，支持实时归档及延时删除。通过数据生命周期管理功能，用户可以更加高效的定义数据生命周期，使存储的利用更加高效。

11.2 XSKY可靠性

分布式存储XSKY作为一种与计算融合的存储软件，通过在服务器上部署该软件，可以将所有服务器的本机磁盘组织成一个虚拟存储资源池，在某些使用场景下完全替换外置SAN。XSKY使计算和存储高度融合，达到高性能、高可靠、高性价比。

• 数据存储冗余设计

（1）副本

XSKY支持用户数据按照设定的1-6副本进行冗余存储。如下图所示，以3个节点组成一个资源池，存储数据为两副本的简单模型为例，任意1个节点上的主副本数据，其备副本数据会均匀分布在其他节点上，单点故障系统不会丢失数据。

XSKY数据三副本存储示意图

• 两副本场景下，在XSKY一个资源池内，出现一个节点或一块磁盘故障，整个系统不会丢失数据，不影响业务正常使用。

• 三副本场景下，在XSKY一个资源池内，出现两个节点或两块磁盘同时故障，整个系统不会丢失数据，不影响业务正常使用。

XSKY系统数据持久度在两副本场景下，达到4个9，在3副本场景下数据持久度达到7个9。

（2）EC纠删码

• 故障域隔离设计

故障域指有共同单点故障的服务器（如同一个机架）组成，数据副本分布到不同故障域，保障数据安全。可以为机架、服务器、硬盘提供故障恢复能力。无论磁盘、服务器发生硬件故障，甚至整个机架出故障，也不会造成停机或数据丢失。下图每个机架设置成一个故障域，如果创建一个2副本存储池，则不同副本数据一定会自动化分放在不同的机架里，这样即使机架A出现故障（如断电），也不会停机或数据丢失。

XSKY多故障域示意图

• 数据强一致性

XSKY采用强一致性复制协议来保证多个副本数据的一致性，即只有当所有副本都写成功，才返回写入磁盘成功。正常情况下XSKY保证每个副本上的数据都是完全一致，从任一副本读到的数据都是相同的。如果某个副本中的某个磁盘短暂故障，XSKY会暂时不写这个副本，等恢复后再恢复该副本上的数据；如果磁盘长时间或者永久故障，XSKY会把这个磁盘从群集中移除掉，并为副本寻找新的副本磁盘，再通过重建机制使得数据在各个磁盘上的分布均匀。

数据强一致性示意图

• 令牌桶I/O流控技术

分布式存储系统中，除了上层应用的业务IO外，系统后台还有定期的磁盘数据扫描，当出现磁盘故障时的数据重建等。当系统的IO业务流量超出系统规格，或者系统扩容时大量的数据迁移、磁盘故障时的数据重建，都可能导致磁盘IO拥塞，IO时延增大。在这种情况下，如果不进行流控，常常造成系统不可用，进而导致业务崩溃。

XSKY开发了基于令牌桶的IO流控技术，支持IO资源过载流控。当IO过载时，根据流控策略有选择的减少低优先级业务，优先保证一定的高优先级业务成功。根据系统的过载程度，流控模块相应的调整系统处理的IO业务量，尽快恢复系统到正常负载。

令牌桶算法（token bucket）：IO系统中设置一个固定容量的桶，桶里存放着令牌（token），桶一开始是空的，token以一个固定的速率r往桶里填充，直到达到桶的容量，多余的令牌将会被丢弃。每当一个请求过来时，就会尝试从桶里移除一个令牌，如果没有令牌的话，请求无法通过。

如上图所示，有三个线程，一个线程以给定的速率不停的产生令牌，一个线程在产生IO包并放到Q1队列，如果有令牌则处理放到Q2中，没有令牌则产生令牌后判断是否能处理IO包，第三个线程在处理Q2队列的IO包。

引入令牌桶IO流控技术后，XSKY分布式存储能应对各种异常对IO的冲击，增强系统鲁棒性。

• 磁盘数据可靠性

XSKY支持硬盘S.M.A.R.T检测、快慢盘检测、磁盘SCSI错误处理、硬盘热插拔和识别处理、磁盘扫描等，上层业务根据Smart Data返回的相关IO错误和磁盘状态信息， 完成读修复、有效数据磁盘扫描及纠错、Smart超阈值告警和处理。

• 读修复功能（Read Repair）

Read Repair是一种在读操作时，当发现有读失败，会判断错误类型，如果发现是磁盘扇区读取错误，可以通过从其它副本读取数据，然后重新写入的方法进行恢复。这是磁盘的特性，对大部分读扇区错误可以修复。如果此方法还不能修复，那么就通过隔离流程为副本选择其它硬盘并把故障的硬盘踢出集群。

• 有效数据磁盘扫描及纠错

通过对数据进行读取扫描，防止静默数据错误(silentdata corruption)，如果扫描失败出现坏道(返回扩展的EIO)，则进行更细粒度的扫描出具体是哪些扇区故障，针对故障扇区进行读修复。

• Smart超阈值告警和处理

当检测到超阈值或者慢盘时，发出告警，系统优先将该盘上的主分区迁移，同时预先重建另一份拷贝（如果原有为2份拷贝，新增1份变为3份拷贝），待这份拷贝重建完成后，再将超阈值或慢盘进行移除磁盘处理。

• 故障检测

支持免人工干预的磁盘、主机自动故障检测和报警。

• 故障自愈

支持在更换磁盘、主机后自动进行数据重建和均衡，且数据重建速度可设置。

• 一致性

支持后台数据一致性校验。

11.3  XSKY扩展性

• 性能容量线性增长

XSKY的分布式架构具有良好的可扩展性，支持超大容量的存储：

• 扩容存储节点后不需要做大量的数据搬迁，系统可以快速达到负载均衡状态。

• 支持灵活的扩容方式，可以独立扩容计算节点、硬盘、存储节点，或者同时进行扩容。在扩容计算节点时同步扩容存储空间，扩容后的系统仍旧可以是计算和存储融合。

• 机头、存储带宽和Cache都均匀分布到各个节点上，系统IOPS、吞吐量和Cache随着节点的扩容而线性增加。

• 数据自动负载均衡

XSKY的CRUSH机制可以保证上层应用对数据的IO操作会均匀分布在不同服务器的不同硬盘上，不会出现局部的热点，实现全局复负载均衡。

• 系统自动将每个卷的数据块打散存储在不同服务器的不同硬盘上，冷热不均的数据会均匀分布在不同的服务器上，不会出现集中的热点。

• 数据分片分配算法保证了主用副本和备用副本在不同服务器和不同硬盘上的均匀分布，即，每块硬盘上的主用副本和备副本数量是均匀的。

• 扩容节点或者故障减容节点时，数据恢复重建算法保证了重建后系统中各节点负载的均衡性。

• XSKY采用的CRUSH算法具有以下特点：

• 均衡性：数据能够能均匀的分布到所有的节点中。

• 单调性：当有新节点加入系统中，系统会重新做数据分配，数据迁移仅涉及新增节点，现有节点上的数据不需要做很大调整。

• 适应性：与DHT不同的是，CRUSH在做数据分布计算时，算法是可以动态调整的，当系统中出现性能、负载不一致的节点时，CRUSH算法可以根据调整输入参数优化算法，重新平衡负载。

11.4  XSKY运维管理平台

XSKY的管理Portal用户按角色分为系统管理员和存储资源管理员，提供的管理功能可分为资源接入和配置、资源管理和维护、系统管理和维护三类。

• 资源接入和初始配置

资源接入主要是服务器的接入，支持单台服务器接入和批量导入两种方式（可在Portal上下载批量导入模板）。服务器接入前需要安装操作系统，然后在Portal上输入待接入服务器的管理IP等信息。服务器接入后可在Portal上为其安装XSKY Agent。

Portal为初始业务配置提供向导式操作。四步完成包括集群网络配置、控制集群、存储池、块客户端在内的基础业务配置。

• 资源管理和维护

资源管维护包括系统概览汇总信息、资源池管理、块客户端管理、卷管理、虚拟文件系统管理、硬件管理等。

系统概览汇总截图

资源池管理截图

资源池管理可查看选定资源池的统计信息和告警信息，查看选定资源池的硬盘拓扑，为选定资源池扩容、减容，以及删除资源池。还提供创建新资源池功能。

块客户端组管理截图

块客户端管理提供创建、删除客户端功能。也提供查看块客户端的挂载信息与CPU 及内存的监控统计信息，为块客户端进行挂载和卸载卷等操作。

卷管理截图

卷管理提供卷的创建和删除功能。创建卷需指定资源池、卷名、卷大小等信息。对于创建后的卷若按SCSI协议使用需要挂载卷，若按iSCSI协议使用需要做iSCSI 映射。还提供iSCSI卷映射界面完成创建主机/主机组、配置启动器、配置CHAP认证、为主机/主机组映射/解映射卷等操作；如果使用FC、Local也需要做类似操作。

服务器管理截图

硬盘管理截图

硬件管理包括服务器管理和磁盘管理。服务器管理对系统中的所有服务器集中管理管理，可查看服务器的软件安装状态、软件版本号、是否加入集群，可查看在服务器上创建的存储池状态以及存储池在该服务器的拓扑信息，支持将服务器设置为维护模式以方便对服务器进行故障恢复处理，支持对服务器的CPU、内存进行性能监控。池畔管理将系统中所有的磁盘集中管理，支持查看磁盘的状态、槽位号、序列号、磁盘使用率、类型等，支持磁盘包括IOPS、时延、带宽、利用率等监控性能统计。

• 系统管理和维护

用户管理截图

系统管理员可以创建新的管理员，为该管理员赋予一定的管理权限，以便多个管理员按照所授权限进行系统或资源管理。对用户的操作包括：查询、删除、创建、解锁、冻结用户等。支持设置密码策略以提升系统安全。

告警截图

系统提供告警查看与统计功能。

监控截图

支持按对象类型统计性能数据，包括存储池、主机、磁盘、卷等对象的IOPS，时延与带宽等。

12. XSKY解决方案的优势和价值

12.1 最优性能

CRUSH数据路由算法 + 多级智能CACHE + 块持久化系统（Blocklayout Persistent System）提升系统极致性能。

一般的基于分布式文件系统做的块存储，性能很难满足云计算下vm和数据库的需求，XSKY全新设计了免锁化、免元数据化、低时延的分布式块存储软件系统，才满足了云计算中vm和数据库的需求。

CRUSH算法替代元数据方式，解决了元数据寻址效率低下问题。同时也解决DHT数据分布不均匀的问题。

XSKY自研分布式Cache算法，支持SSD读写Cache，在SSD Cache的加速下可以让客户使用SATA的投资获得SSD的性能。事实上目前业内很多分布式存储厂商不支持使用SSD做写Cache。

XSKY自研BPS（Blocklayout Persistent System）管理硬盘上的数据空间管理，而业内很多分布式存储软件厂商使用本地文件系统（如XFS）进行磁盘管理，由于增加了文件系统的开销，使得端到端的IO性能、以及空间利用率都不高；同时文件系统存在很多自发性操作，例如刷page cache，会导致磁盘压力不均衡，影响业务。

12.2 大规模集群建设经验

到目前为止，XSKY负责的最大项目数据规模达到3PB，文件个数规模达到数十亿；参与项目的最大集群规模30PB。

12.3 支持异构环境

许多客户在使用SDS的时候面临这样一个问题，原有服务器如何利用？与部分友商不一样的是，XSKY存储支持异构服务器，可以将不同类型、配置的服务器放置在同一存储系统中，共同使用，解决企业利旧问题，提升资源使用率。

12.4 兼容性更好

XSKY支持Bare-metal（物理服务器应用）和虚拟化两种应用，虚拟化支持KVM、Vmware、XEN以及HyperV等多种应用。支持业内主流的虚拟化软件、OpenStack云平台、以及数据库软件，比如VMware、RedHat OpenStack、Mirantis OpenStack、Oracle数据库、DB2数据库、HANA数据库等。

12.5 应用场景更丰富

XSKY支持10GE、40GE以及Infiniband高速互联网络，可以应用于OLAP和OLTP等数据库高性能应用场景。XSKY支持非常丰富的接口，包括块存储（iSCSI、FC、Local SCSI以及rbd）、对象（S3、Swift）和NFS文件系统。使用XSKY的存储产品，可以构建从核心存储到私有云、混合云再到公有云的全栈存储系统。业务应用从虚拟化、数据库到备份，提供全套解决方案。

12.6 可靠性更高

超过10年存储经验的产品化团队，专业维护团队，多个PB级项目经验；

12.7 特性和性价比的长期竞争力

XSKY是Ceph社区的重要参与者，向社区提供了异步消息模块、RDMA模块等重要模块，在反馈社区的同时也与社区共同成长，将社区非常优秀的算法、功能与企业市场特征相结合，进行产品化。如今，Ceph社区非常健康，高度发展，也形成了XSKY的长期竞争力。

本方案为 2021 容器云职业技能大赛架构师岗优秀方案作品

点击文末阅读原文，可下载该方案文档

觉得本文有用，请转发、点赞或点击在看，让更多同行看到

欢迎关注社区分布式存储技术主题，将会不断更新优质资料、文章。地址：

https://www.talkwithtrend.com/Topic/23951

下载 twt 社区客户端 APP

长按识别二维码即可下载

或到应用商店搜索twt

长按二维码关注公众号

*本公众号所发布内容仅代表作者观点，不代表社区立场