云存储架构浅析及应用分析

云存储架构浅析及应用分析

秦君洪灿文李晓敏

(云南电网有限责任公司德宏供电局云南德宏678400)

摘要：随着信息化技术的发展，云计算及相关的技术应用越来越普遍，关于非结构化文档的云存储的系统架构和技术实现已经十分迫切，在现有的情况下，存储的按需扩展、高可用、分布式搜索架构进行了探索，实现了基于私有云存储的架构。

关键词:云存储

对于云存储的系统架构，通常需要从存储安全性、可用性、一致性以及扩展能力几个层面来考虑。云存储的系统架构通常由对象存储层、集群管理监控两个主要的部分组成，前者解决数据存储层面的冗余安全性、一致性和可用性，而集群管理监控层面解决云存储集群的服务高可用、系统扩展、管理与监控的能力。

谈到对象存储，虽然有众多流派，但是主流的还是OpenStack项目中的Swift。Swift是OpenStack开源云计算项目的子项目之一，提供了强大的扩展性、冗余和持久性。Swift并不是文件系统或者实时的数据存储系统，用于永久类型的静态数据的长期存储，这些数据可以检索、调整，必要时进行更新。最适合存储的数据类型的例子是文件存储、图片存储、邮件存储和存档备份，因为没有中心单元或主控结点，Swift提供了更强的扩展性、冗余和持久性。

扩展性分两方面，一是数据存储容量无限可扩展;二是Swift性能(如QPS、吞吐量等)可线性提升。因为Swift是完全对称的架构，扩容只需简单地新增机器，系统会自动完成数据迁移等工作，使各存储节点重新达到平衡状态。

Swift的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。整个Swift集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。Swift提供的服务与AmazonS3相同，适用于许多应用场景。最典型的应用是作为网盘类产品的存储引擎，比如Dropbox背后就是使用AmazonS3作为支撑的。

如果集群中的数据在本地节点上只有一份，一旦发生故障就可能会造成数据的永久性丢失。因此，需要有冗余的副本来保证数据安全。Swift中引入了Replica（副本）的概念，其默认值为3，理论依据主要来源于NWR策略(也叫Quorum协议)。NWR是一种在分布式存储系统中用于控制一致性级别的策略。在Amazon的Dynamo云存储系统中，使用了NWR来控制一致性。其中，N代表同一份数据的Replica的份数，W是更新一个数据对象时需要确保成功更新的份数;R代表读取一个数据需要读取的Replica的份数。公式W+R>N，保证某个数据不被两个不同的事务同时读和写;公式W>N/2保证两个事务不能并发写某一个数据。在分布式系统中，数据的单点是不允许存在的。即线上正常存在的Replica数量为1的情况是非常危险的，因为一旦这个Replica再次出错，就可能发生数据的永久性错误。假如我们把N设置成为2，那么只要有一个存储节点发生损坏，就会有单点的存在，所以N必须大于2。N越高，系统的维护成本和整体成本就越高。工业界通常把N设置为3。例如，对于MySQL主从结构，其NWR数值分别是N=2,W=1,R=1，没有满足NWR策略。而Swift的N=3,W=2,R=2，完全符合NWR策略，因此Swift系统是可靠的，没有单点故障。

对于整个云存储而言，第二个要考察的就是系统的高可用和负载均衡能力，一个高可用的集群，在集群中，各个节点本身不能保留独立的状态信息，否则在故障中，系统的数据和信息一致性会受到影响。所以，在集群中，一般设定了单点无状态的约束：

本地无动态配置文件，本地配置不保存，不永久化

单点不拥有全局状态，节点本地状态本地缓存（内存Cache）

全局信息/集群节点/软件的配置由集群database拥有(EGBase)

单点无状态设计的好处是：

集群里各个节点可以被灵活的调度到新的状态和角色

在集群发生变化，节点状态/角色变化时，可以自由切换

单点无状态需要处理的例外情况

数据库配置与数据库数据表，需要永久化，防止配置丢失，防止大量数据同步；

数据存储（Swift内数据）不丢失防止大量数据重新同步（节点Swift配置不永久化）；

节点软件/设备的初始状态；

一些不被故障探测的设备重启需要配置永久化，如网络配置，因为正常情况下可重启。

集群的负载均衡，通常在软件层面实现，可以采用LVS来实现，LVS采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。

LVS的主要模式有VS/NAT、VS/TUN和VS/DR模式，根据性能、安全性的综合考虑，在做好网络安全前置防控的基础上，最佳的选择是DR模式。

2.2云存储的开放架构

对于云存储的开放性，是我们整个系统建设的一个基础，特别是面向供电局的各类业务应用，实现文档的统一归档、搜索，至关重要。

其实对于开放性而言，最佳的做法就是基于HTTP/S协议的WebService。综合考虑到现有的业务情况，我们认为最佳方式是采用RestFul接口规范，为现有各类供电局应用系统，提供面向整合的平台资源访问和操作接口。在获得授权的情况下，开发者可以通过如下提供的接口开发基于该云平台的相关应用程序。

开放API涉及的范围至少包括：

文档访问类API，包括：

文件类操作阶段，包括上传、下载、删除、重命名；

获取文件历史版本，包括历史版本恢复、下载；

文件回收站，包括浏览回收站、还原、清除回收站文件；

目录类操作接口，包括创建、修改、删除、浏览；

全文检索接口；

权限类API：

统一身份认证接口；

文档操作权限接口；

2.3网盘的自动同步与共享协作模型

根据Gartner的报告，企业级的网盘应用称之为EnterpriseFileSync&Sharing（EFSS），这个市场中比较典型的是BOX、ShareFile（Citrix）、Accellion、Syncplicity（EMC子公司）等，他们的核心在于两个方面，一个对于最终使用者，多终端自动同步、简单易用的体验，一个是对于企业管理者，安全可控。

个人网盘很明显不能满足大理供电局的管理需求，无论是百度云盘还是360云盘。国内的企业网盘，包括金山企业网盘、联想企业网盘，还有爱数的AnyShare文档云，各有优势。

实际上，各个网盘在移动端的差异性不大，我们重点考虑日常办公中常用的PC桌面客户端的同步共享模式。在PC客户端模式上，概括下来，主要是三种模式：

第一种是富客户端模式，通过客户端界面操作文档，包括打开、修改、删除，主流的百度云盘、360云盘都是这种模式，这种模式有一定的操作成本，文件必须先上传到云端，才能自动的同步（修改后），而实际用户的使用行为也会有一些区别，虽然也有一些客户端可以支持在富客户端新建文件，但是受限于客户端程序本身模拟的程度。

第二种模式是Windows文件夹自动同步模式，这种模式有一些企业网盘采用的选择性同步，也就是选择某个文件夹到本地缓存目录，形成自动同步，但是这种模式最大的问题在于用户不知道如何选择，特别是企业文件量那么大的情况下，如何知道哪些文件是需要同步下来，哪些不需要？比如爱数的AnyShare就是基于这个改良是基于文件系统层监控模型，本地看到云端虚拟文件/夹对象，根据用户的操作行为（打开、复制等）来触发加载动作。Windows文件夹自动同步，加上按需加载模型，基本上达到了完全Windows操作习惯，所以对于职工而言，学习难度和操作成本是最低的，也是目前比较好的解决方案。

第三种模式是类似于NFS/CIFS网络文件系统的挂载模式，这种模式看起来是最佳的，按需加载内容，本地不留缓存或者只有局部少量缓存，这种模式的原理在于用户态文件系统，但是最大的问题就在于Windows没有类似Linux下FUSE这种原生用户态文件系统，所以技术方案是模拟驱动，没有非常成熟的技术方案，导致在Windows下基本不可行。

所以，综合下来，我们选择第二种方案作为网盘的基本使用模型，特别是对于大理供电局这样大量职工一直习惯Windows环境，这种方式的学习成本最低，而且最可靠。

在第二种方案的基础上，还需要考虑的是文件的协作一致性问题，也就是多个人同时打开文件编辑的情况，在传统的文件服务器或者NAS共享模式下，采用的是WriteOnly,ReadMany的锁定写模式，也就是第一个具有写权限的打开后锁定文件，其他人只能以只读模式打开，这种方式本质上是文件系统层的特性，在网络云存储的情况下，怎么处理呢？

第一种方案是类似于SVN/CVS一样的，基于提交、更新、冲突解决的方式来协作，冲突不可避免，基于服务器端版本的基准来决定是否存在多人基于同一基准的不同版本更新，从而让用户自主决定冲突解决后提交。这种方案适用于软件研发团队，专业性和复杂度都过高。

第二种方案是基于云存储的在线编辑协作模式，这种模式核心是在线的编辑应用，比如GOOGLEDOC，这种模式下，同时在线编辑的人是相互可见内容变化的，比较适用于团队协作规范的情况，也就是一个文件，几部分分别由谁来负责更新，否则的话，也会面临不知所措的情况。而且这种模式支持的文件类型是非常有限的。

第三种方式就是模拟CIFS共享，基于锁定来进行串行协作，自动锁的模式，在Windows的文件夹下面打开云端文件，自动锁定，其他打开者就只能以只读方式打开，当修改完毕后，自动解锁，或者异常情况下，由服务器来自动解锁，实现简易的自动锁定串行协作机制。

综合下来，我们认为基于Windows文件夹按需加载同步模型，配合自动锁协作机制，相对来说使比较符合职工的工作习惯和共享协作需求。

参考文献：

[1]唐箭.云存储系统的分析与应用研究[J].电脑知识与技术,2009,5(20):5337-5338.

[2]李曦蔓.云存储安全构架分析及关键技术研究[J].科技经济市场,2015(2):13-14.