分布式存储介绍
分布式存储系统是网络存储的一种，依赖于以太网络实现数据交互。传统的网络存储系统（如NAS）采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，并单点故障，不能满足大规模数据存储的需要。而分布式存储系统，是将数据分散存储在多台独立的存储节点（服务器）上。分布式存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，可以有效地提高存储系统的可靠性、可用性和可扩展性。分布式存储系统在设计的时候，也需要遵循分布式系统设计的CAP（一致性、可用性、分区容错性）原则，具体说明如下：
- 一致性：分布式存储系统会使用多台服务器共同存储数据，为了保证在有服务器出现故障的情况下系统仍然可用，会把一份数据分成多份存储在不同的服务器中，这种做法也称为多副本机制。但是由于故障和并行存储等情况的存在，同一个数据的多个副本之间可能存在不一致的情况。分布式存储要极力避免出现副本间数据不一致的情况，所以在副本可用的情况下，分布式存储系统都是要求强一致性的，也即一个数据只有对两个副本的写都完成才能返回成功。
- 可用性：分布式存储系统要求单个（甚至2个）节点的故障不影响整体系统的可用性，这就要求同一份数据的副本必须分布到不同的节点上。
- 分区容错性：分布式存储要尽力避免网络中断造成的分区影响，比如1个或者2个节点的网络中断不影响整个集群的服务能力。这就要求分布式存储要对集群内的节点网络可用性有良好的探测和隔离机制，一旦某个节点的网络出现故障、可以被快速的被隔离，集群内其它好的节点可以根据策略决定是否重建副本。
此外，分布式存储还需要考虑节点间的负载均衡和容量均衡，也即负载和容量尽量平均地分配到所有节点上。所以对于分布式存储来说，数据分布算法是核心，目前主流的算法有一致性哈希算法和CRUSH算法。比如Swift对象存储使用就是一致性哈希算法，Ceph使用的就是CRUSH算法。
分布式存储在金融行业的前景
分布式存储目前在金融行业还没有得到大规模的推广，主要是金融机构现有应用架构对存储的要求，和分布式存储可以提供的能力之间有一定的差距。金融机构目前使用存储最多的场景主要是共享块存储（如数据库、VMware虚拟化集群、共享文件系统）。NAS由于在性能和可靠性方面不如SAN存储，也没有得到大规模的使用。提供共享存储恰恰是分布式存储的劣势，目前主流的分布式块存储都基本不提供共享存储能力，分布式共享文件系统虽然可以提供共享存储能力，但是都不支持多文件系统，只能一个存储集群提供一个共享文件系统，这距离不同应用使用不同文件系统的要求差距还很大。当然，这并不能说分布式存储的设计有很大问题，而是分布式存储从诞生之初，就不是用来替代传统的SAN存储的。它最初的设计用途是为了给云计算的计算节点提供块和对象存储能力。云计算的虚拟机基本没有共享块存储的需求，如果一定需要共享文件，也可以通过对象存储解决，所以在很长时间对于共享块存储的需求是基本忽略的。至于对象存储，大部分金融机构应该还没有想好使用场景和使用方式。
分布式存储经过十多年的发展，也开始逐渐引入一些传统SAN存储支持的能力，希望能够在企业数据中心拓宽其使用范围。那么，现阶段分布式存储适合于那些应用场景呢？我们根据自己的实践经验总结如下：
- 基于KVM虚拟化的云计算场景：VMware虚拟化集群仅仅对自家的VSAN支持较好，其它的分布式存储只能通过iSCSI方式支持。而iSCSI是一种点对点的存储通信协议，很容易因为网络抖动或者iSCSI机头设备故障受到影响，此外统一的机头入口也是性能瓶颈点，无法满足金融机构对存储可靠性和高性能的要求。但是如果使用基于KVM虚拟化的云计算技术就不存在这样的问题，比如OpenStack，已经能够很好的将主流的商业和开源分布式存储用于为KVM虚拟机提供块存储。
- 容器使用场景：容器技术在发展初期，就很好的拥抱了分布式存储技术。容器所需要的持久化存储就需要依赖分布式存储。目前主流的容器编排系统（如Kubernetes）可以很方便的使用各种主流的商业或开源分布式存储技术。
- 文件共享场景：传统的文件共享主要通过共享文件系统、或者FTP来解决。共享文件系统为了确保不同业务间的数据安全隔离，只能为一类业务系统建立独占的共享文件系统，共享范围受限，成本高昂。使用FTP可以扩大共享范围，但是FTP服务性能受限于单个FTP服务器的性能，并且缺少比较好安全管控手段（如白名单）。分布式存储，特别是对象存储就比较适合这种场景，它不存在单点性能瓶颈，分布式的性能和可靠性也会更高，同时还能提供多租户的隔离机制。
分布式存储发展方向
分布式存储最开始的目的是支持云计算（特别是公有云）和大数据的数据存储，在这些方面已经证明了自己的能力，现在或者将来的重点方向是走向企业数据中心市场。为了满足企业数据中心的要求，分布式存储需要重点发展如下能力：
- 共享块存储能力：企业数据中心目前对块存储的重点需求就是共享块存储，谁能更早的满足这个需求，谁就能更快的打开局面，赢得市场先机。目前个别商业分布式存储已经开始逐步支持共享块存储的需求，这样受限就能满足传统数据库和共享文件系统对共享存储的需求。接下来，还需要继续推进和主流虚拟化产品（如VMware、KVM）的结合。简单来说，就是在共享块存储能力方面要和传统的SAN存储持平。
- 跨数据中心容灾能力：分布式存储普遍在跨数据中心容灾能力上较弱，集群内多副本机制并不能很好的解决这个问题。企业数据中心希望的容灾能力是类似传统SAN存储那样的同城和异地容灾能力。传统SAN存储能够做到同城实现数据同步复制，异地实现异步复制。但是目前的分布式存储同城之间只能做到异步复制，无法满足企业对RPO为零的要求。
- 支持多文件系统的能力：现有的分布式文件系统都只能支持一个文件系统，在数据隔离性方面不能达到要求。企业数据中心需要的是对多文件系统的支持，把分布式文件系统看成一个资源池，不同应用可以被分配不同的文件系统，彼此之间完全逻辑隔离，同时提供相应的访问权限控制机制。
- 混合部署能力：分布式存储需要支持在同一集群内混合部署不同类型存储池，比如SATA、SAS和SSD，实现分级存储，满足不同业务对性能的多样要求。现有的一些商业或开源分布式存储产品已经支持混合部署，但是通常需要去手工编辑类似CRUSH Map这样的核心配置文件，每次更换或者新增硬盘也都需要手工编辑，这给生产运营带来巨大的风险，很容易由于误操作导致数据丢失或者集群不可用。正确的方式应该是实现对存储池的全自动化管理，让分布式存储系统自身自动化的识别节点或者硬盘变化，避免人为干预。
- 硬盘亚健康状态检测：分布式存储的存储节点都使用服务器的本地硬盘作为数据存储盘，一旦某一个硬盘出现亚健康状态导致单盘性能下降，将会对整个集群的性能产生影响。因此需要分布式存储自己就能及时发现性能明显下降的硬盘，并将其隔离出去。
分布式存储部署使用原则
分布式存储在部署使用的时候，需要充分考虑到将可用性和性能提升到最高，通常应该遵循如下原则：
- 在生产和灾备端各构建一个统一的集群提供存储供给能力，同一站点不搞多集群。这样便于维护，也能最大效率的实用分布式存储的横向扩展能力，降低成本。在统一存储池内，划分不同级别的存储能力，比如SATA和SSD，满足不同业务类型的需求。
- 从客户端角度，为了满足高速存储需要的大带宽，必须构建单独的万兆存储IP网络，和业务网络分开。这就要求从网络设计、服务器选型、布线接入、虚拟化都要做调整。比如物理服务器必须有额外的存储网络接入网卡、虚拟机也必须有额外的存储虚拟网卡。
- 为了避免机柜电源故障导致集群故障，所有的计算节点和存储节点都部署在不同列的机柜中。
- 为了避免更换故障盘时人为误操作导致事故，所有的操作都脚本化、自动化。运维人员所需要做的就是把状态异常的盘从集群中剔除，带新盘更换完毕后，运行一条命令就可以自动发现新盘，并将新盘加入集群。
- 为了避免亚健康状态的硬盘拖累整个集群的性能，需要部署硬盘亚健康状态自动监测和自动隔离工具。
- 为了避免存储节点重启后产生大量的数据复制，需要调整分布式存储的数据恢复策略，节点宕机或重启并不做数据rebalance，而是等节点恢复后同步增量数据
- 应用端使用对象存储，需要充分考虑容灾实现，也即在写入的时候向生产、灾备两个集群同时写入，读取的时候从某一个集群优先读取。单个集群的失效不影响应用的写入和读取返回状态，有些类似存储端做镜像的概念。
分布式存储部署架构
一个最小规模的可用于生产的Ceph集群部署架构如下，包含3个Monitor节点和4个存储(OSD)节点。其中，Monitor节点运行MON、MDS和RGW(RadosGW)实例，是对外提供服务接口的节点；存储节点主要运行OSD示例，分配和存储数据。
为了使集群性能达到最优，需要使用SSD盘来存放Metadata和journal。这样每个Monitor节点需要2个SSD盘做Raid来存放Metadata，每个OSD节点需要2个SSD盘(非Raid)来存放journal。私有网络是用来做节点间消息和数据传递，特别是OSD节点间在做数据恢复时会产生大量的I/O，因此OSD节点间的私有网络都是采用万兆网络接入。Monitor节点之间以及Monitor和OSD节点间之间不涉及大吞吐量操作，因此Monitor节点通过千兆网络接入私有网络即可，这样可以节省成本。公共网络主要用于对外提供存储服务，因此所有节点都采用万兆接入。