CN102394923A - 一种基于n×n陈列结构的云系统平台 - Google Patents

Abstract

本发明涉及一种基于n×n陈列结构的云系统平台，对于云存储层次结构主要包括本地或局域虚拟存储层和虚拟资源层、分布式高可靠性大文件云存储层、基于表的结构云存储层、流数据云存储层、云存储安全访问接口层、云存储应用层。本发明采用网卡直接相连，利用本地存储实现大容量的在线高速存储，并且在每个节点配置USB2.0或者3.0接口和对应的硬盘作为后备存储，采用RAID10的NAS作为远程备份存储；同时，通过设置六层系统框架结构，可为构建通用的云存储平台创造有利条件；具有性价比较高、可靠性高、可扩展性较佳、高网络带宽等优点，特别适用于服务器虚拟化环境和高速实时处理海量数据环境。

Description

一种基于n×n陈列结构的云系统平台

技术领域

本发明涉及云计算与云存储技术，尤其涉及一种基于n×n陈列结构的云系统平台。

背景技术

一般的私有云或者公有云系统，在物理上一般采用共享交换机模式；云存储采用集中存储模式，这些结构的缺点是交换机的总带宽系统的功能制约性影响较大，同时，交换机故障还会导致整个云系统崩溃；同样，集中存储模式中，存储控制卡故障必将导致系统崩溃，这种系统的修复时间很长，并且价格很贵。随着云计算和云存储开源软件的大量普及，原有的单服务器系统向云端迁移成为必然，如何构建与之对应的“云”和云存储软件相适应的环境，成为研究的热点；由于云计算和云存储环境中应用软件大量使用网络带宽，如何组织网络系统结构、云存储软件系统构架，使系统在虚拟化后对IO和网络影响减到最小、提高系统的网络吞吐量、可靠性、可维护性、安全性。此外，以太网结构的最大问题是信号的碰撞问题以及由此引起的在网络忙时的系统不稳定和难以提供可靠的实时服务；随着千兆以太网的大规模普及，对应的交换机和网卡的性价比非常低廉，性能非常稳定和可靠，在1个机柜内的节点通过节点与节点链接构建集群在技术上已经成熟。因此，结合以上分析，需要对现有技术进行有效更新。

发明内容

针对以上缺陷，本发明提供一种基于n×n陈列结构的云系统平台，其采用网卡直接相连、利用本地存储(DAS)实现大容量的在线高速存储、并且在每个节点配置USB2.0或者3.0接口和对应的硬盘作为后备存储、采用RAID10的NAS作为远程备份存储、具备六层系统框架结构，以解决现有技术的诸多不足。

为实现上述目的，本发明采用以下技术方案：

一种基于n×n陈列结构的云系统平台，对于硬件框架结构的实施主要包括以下：

(1)首先，直接通过网卡直连方式进行节点内服务器可靠通信，在系统应用层网络通信采用UDP直接通信，在应用层可靠性设计时利用其它n-1个节点进行并行计算或者通信，在复制文件时，先在本地节点把文件切块为n等分，然后通过多进程技术利用n条路由把文件从任何个节点copy到其它节点，并且采用RIAD5类型的海明校验技术，这些检验块在不同的节点中；

(2)然后，选择服务器安装LINUX操作系统，并且做root用户的互信，服务器之间的文件传输直接通过scp命令进行；

(3)同时，需要每个服务器建立一个/ULOC/IP地址/disk+逻辑磁盘编号的文件夹，通过SAMBA协议访问对应的物理机器磁盘文件，使用CIFS文件系统的主要目的使是linux和windows都可访问，并且是通过网络点到点通信访问的，CIFS协议的开销基本可以忽略不计；另外，若用户需要使用逻辑上只有一个目录的云存储，通过点到点通信结构配置MOOSEFS文件系统或者配置为ISCSI设备，利用OPENFIRE在ISCIS层实现从设备层对存储资源的逻辑上统一的访问；或者在LINUX环境下作对应文件夹的软链接来实现。

(4)最后，机柜之间的通信采用在机柜的序号最大的节点加1万兆网卡，与下一个机柜的序号最小的机器加1万兆网卡的此网卡通信；

对于云存储层次结构的实施主要设置以下六个层次：

即本地或局域虚拟存储层和虚拟资源层、分布式高可靠性大文件云存储层、基于表的结构云存储层、流数据云存储层、云存储安全访问接口层、云存储应用层。

本发明所述的基于n×n陈列结构的云系统平台的有益效果为：该技术采用网卡直接相连，利用本地存储(DAS)实现大容量的在线高速存储，并且在每个节点配置USB2.0或者3.0接口和对应的硬盘作为后备存储，采用RAID10的NAS作为远程备份存储，由于其性价比高，必将成为在可靠节点上的云计算和云存储体系结构的发展方向；同时，通过设置六层系统框架结构，可为构建通用的云存储平台创造有利条件；具有性价比较高、可靠性高、可扩展性较佳、高网络带宽等优点，特别适用于服务器虚拟化环境和高速实时处理海量数据环境。

附图说明

下面根据附图对本发明作进一步详细说明。

图1是本发明实施例所述基于n×n陈列结构的云系统平台的逻辑结构图；

图2是本发明实施例所述基于n×n陈列结构的云系统平台的云存储层次示意图。

具体实施方式

如图1所示，本发明实施例所述的基于n×n陈列结构的云系统平台，对于硬件结构实施方式，主要包括以下：

(1)首先，直接通过网卡直连方式进行节点内服务器可靠通信，在系统应用层网络通信采用UDP直接通信，由于肯定存在n-1条到目的地的经过一级路由，在应用层可靠性设计时利用其它n-1个节点进行并行计算或者通信，在复制文件时，先在本地节点把文件切块为n等分，然后通过多进程技术利用n条路由把文件从任何个节点copy到其它节点，为了保证可靠性，采用与RIAD5类似的海明校验技术，这些检验块在不同的节点中，速率可达到千兆的n倍且全双工，无需考虑丢包等可靠性的问题；

(2)然后，鉴于使一个机框内服务器的相互资源访问的方便性，选择服务器安装LINUX或者UBUNTO操作系统，并且做root用户的互信，这样服务器之间的文件传输直接通过scp命令进行，方便应用层的资源调度，简化应用层的逻辑设计，保证系统的简单和可靠性；

(3)同时，考虑到对机柜内服务器存储资源的提供一个统一的逻辑访问接口，则需要每个服务器建立一个/ULOC/IP地址/disk+逻辑磁盘编号的文件夹，通过SAMBA协议访问对应的物理机器磁盘文件，使用CIFS文件系统的主要目的使是linux和windows都可访问，并且是通过网络点到点通信访问的，CIFS协议的开销基本可以忽略不计；另外，若用户需要使用逻辑上只有一个目录的云存储，通过点到点通信结构配置MOOSEFS文件系统或者配置为ISCSI设备，利用OPENFIRE在ISCSI层实现从设备层对存储资源的逻辑上统一的访问，或者在LINUX环境下作对应文件夹的软链接来实现；

(4)最后，机柜之间的通信采用在机柜的序号最大的节点加1万兆网卡，与下一个机柜的序号最小的机器加1万兆网卡的此网卡通信，以实现多机柜的互联，并且本身的速率是匹配的。

以上结构框架内部互联主要满足CIFS、NFS、WEBDAV MOOSEFS客户端等支持POSTIX协议的系统或者高层的HTTP、FTP协议和支持基于目录和名称的TCP或者UDP的XML指定协议访问，这些网络文件系统的内部相互访问通过n×n网络，机柜间采用10G网络连接，外部访问通过总线(交换机)进行，由于云计算和存储云内部的网络流量非常大，采用这个结构的优点非常明显，特别适合于虚拟化、云存储、云计算环境。

如图2所示，本发明实施例所述的基于n×n陈列结构的云系统平台，对于云存储层次结构的实施方式，本系统提出适合不同应用的框架并用OPENSTACK的开源框架实现虚拟机的管理、云存储、云计算的API，云存储层次结构框架分为：底层的本地或局域虚拟存储层和虚拟资源层、三种不同类型的云存储层、安全访问接口层和应用层、贯穿三种不同类型的云存储层，主要用于虚拟资源管理系统对云存储层和安全访问接口层进行管理，从基础的存储层到展现的应用层，始终贯穿着云存储安全管理。

具体的层次结构由下至上包括：本地或局域虚拟存储层和虚拟资源层、分布式高可靠性大文件云存储层、基于表的结构云存储层、流数据云存储层、云存储安全访问接口层、云存储应用层。

各层的技术实现详细说明

(1)本地或局域虚拟存储层和虚拟资源层：主要是存储的基础设施，由本地或局域的虚拟存储设备和虚拟资源组成。

云存储的块是虚拟机存储的文件，对云存储来说，相当于传统文件系统中的簇，是云存储访问的最小单位，考虑到在云环境下机器和磁盘的不用性的概率比较高，开启采用定期进程，完成扫描、校验码(crc)等的disk scrubbing和采用rpc(远程过程调用协议)，另外，由于磁盘连续块访问性能好的优点和网络访问的流量问题，云存储的一般都比较大，设计为在64K和64M(可选择)，要求支持连续块append和连续块读操作，提高流文件的读写性能，从而提高访问性能。

该层结构主要创新点在于：本地文件系统在大量小文件的应用时为jfs，否则用RaiseFS(块大小到4M)；网络文件采用SAMBA，SAMBA用在可以共享windows为主机的windows系统的ntfs的本地磁盘和AIX小型机的本地磁盘。

在这层主要实现难点为虚拟机的管理和控制，主要功能有：

(1)虚拟机cluster管理系统：①宿主机资源管理模块：管理宿主机的位置和ip，cluster的运行情况；②虚拟机管理模块：管理所以虚拟机guest-os的在宿主机的位置和ip，如果有内部的cluster，监控这些cluster的状态；③虚拟机宿主机监控模块：监控每台虚拟机宿主机OS的运行状态(Linux运行一个后台服务，监控虚拟机管理相关的后台进程运行状况，内存使用情况，CPU使用情况，IO使用情况，网卡工作情况，磁盘空间分配情况，把这些信息每隔一定周期(可以配置)，写监控表；

(2)虚拟机控制模块：虚拟机-GUEST-OS的SNOPSHOT，定时开机，定时关机，动态分配和回收磁盘，动态分配和回收光盘，动态分配和回收U盘，CPU和内存资源动态分配和回收(分配策略算法)，远程桌面(RDP)，ssh和telnet远程连接；

(3)块内容MD5计算和校验；

(4)坏块的定期扫描和校验；

(5)NFS下NFS系统的定期的网络磁盘测试和校验，故障时的告警(包含本地磁盘的卷)；

(6)disk scrubbing：disk scrubbing在发现校验盘的数据不一致的时候会去自动重新运算出校验数据，然后重写，通过在磁盘上做checksum，这样一旦发生校验盘的数据不一致的时候，把每个磁盘的数据读出来，利用checksum来判断到底是哪个磁盘的数据有问题，一旦定位，就可以利用其余的数据重新运算出错误的数据。

本层是基于不可靠的存储块，使用1+2备份模式，备份分为两种方式：一是跨物理机器的，二是跨交换机和机柜的；由于基于虚拟化的文件系统的访问，具有非常好的可扩展性；根据安全要求，可以进行压缩和加密存储。

(2)分布式高可靠性大文件云存储层(BigFS)：大文件云存储层支持大规模顺序读写数据存储，主要实现虚拟机node(云存储的一个逻辑卷)的管理，实现物理数据存储层的node管理，本层为全局的数据存储的虚拟层，其中上层的结构化数据存储在本层的多个区域，防止由于上层故障时引起系统崩溃；在多个node并发访问和node在不同状态时保持同步和协调，通过锁技术保证分布式资源的协调，从而保证数据操作的一致性(相当于实现自己的CHUBBY服务锁)，本层相当于HDFS。

大文件系统(BigFS)是一个可扩展的分布式文件系统，用于大型的、分布式的、对海量数据进行访问的应用；它运行于廉价的普通硬件上，但提供了容错复制功能，可以给大量的用户提供总体性能较高的可靠服务。

①设计假设：大文件系统与传统的分布式文件系统有很多相同的目标，但大文件系统的设计受到了当前及预期的应用方面的工作量以及技术环境的驱动，因而形成了它与传统的分布式文件系统明显不同的设想，这就需要对传统的选择进行重新检验并进行完全不同的设计观点的探索。

硬件错误(包括存储设备或是存储节点的故障)不再被认为是异常的情况，而是将其作为常见的情况加以处理，因为文件系统由成千上万个用于存储的机器节点构成，而这些机器是由廉价的普通硬件组成并被大量的客户机访问；硬件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复，所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。每个文件通常包含很多应用对象，因为经常要处理快速增长的、包含数以万计的对象、长度达TB的数据集，很难管理成千上万的KB规模的文件块，即使底层文件系统提供支持。因此，设计中操作的参数、块的大小必须要重新考虑；对大型的文件的管理一定要能做到高效，对小型的文件也必须支持，但不必优化。大部分文件的更新是通过添加新数据完成的，而不是改变已存在的数据；在一个文件中随机的操作在实践中几乎不存在，一旦写完，文件就只可读，很多数据都有这些特性，一些数据可能组成一个大仓库以供数据分析程序扫描，有些是运行中的程序连续产生的数据流，有些是档案性质的数据，有些是在某个机器上产生、在另外一个机器上处理的中间数据；由于这些对大型文件的访问方式，添加操作成为性能优化和原子性保证的焦点，而在客户机中缓存数据块则失去了吸引力。工作量主要由两种读操作构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作；在前一种读操作中，可能要读几百KB，通常达1MB和更多，来自同一个客户的连续操作通常会读文件的一个连续的区域，随机的读操作通常在一个随机的偏移处读几个KB，性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来回读。工作量还包含许多对大量数据进行的、连续的、向文件添加数据的写操作，所写的数据的规模和读相似，一旦写完，文件很少改动，在随机位置也支持少量数据的写操作，但并非高效。系统必须高效地实现定义完好的大量客户同时向同一个文件的添加操作的语义。

②系统接口：实现CDMI标准接口API，并实现WEB-DAV接口访问、FTP和FTPS接口访问，HTTP和HTTPS接口访问，并提供了一个相似地文件系统界面，文件在目录中按层次组织起来并由路径名标识。

③体系结构：一个大文件系统集群由一个Master(做drdb)和大量的chunkserver构成，并被许多访问端；Master和chunkserver通常是运行用户层服务进程的Linux机器，只要资源和可靠性允许，chunkserver和Client可以运行在同一个机器上。BigFS文件被分成固定大小的块(block)，每个块由一个不变的、全局唯一的1个64位组成的chunk-handle标识+32位的内容MD5码(可以配置是否需要，否则为全0)组成，chunk-handle是在块创建的时候由Master分配的，MD5由客户端传入或者存块node定时计算(为0时)，chunkserver将块当作Linux文件存储在本地磁盘或者NFS并可以读和写由chunk-handle和位区间指定的数据。出于可靠性考虑，每一个块被复制到多个chunkserver上，默认情况下，保存3个副本，可以由用户指定(至少为2)。Master维护文件系统所有的元数据(metadata)，包括名字空间、访问控制信息(ACL)、从文件到块的映射以及块的当前位置，它也控制系统范围的活动，如块租约(lease)管理，孤儿块的垃圾收集，chunkserver间的块迁移，MD5相同的块合并(在一个LNFS系统内)，Master定期通过HeartBeat消息与每一个chunkserver通信，给chunkserver传递指令并收集它的状态(是否被锁定，流量是否最大，是否在线，磁盘卷是否正常)和块的检测结果信息。与每个应用程序相连的BigFS客户端实现了文件系统的API并与Master和chunkserver通信，以访问文件系统的数据，客户端与Master的交换只限于对元数据(metadata)的操作，所有数据方面的通信都直接和chunkserver联系，访问端和chunkserver都不缓存文件数据；因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存，不缓存数据策略简化了客户端程序和整个系统，因为不必考虑缓存的一致性问题，但客户端缓存元数据(metadata)，chunkserver也不必缓存文件数据，因为块是作为本地文件存储的。

④逻辑上的单Master：只有一个Master也极大的简化了设计并使得Master可以根据全局情况做出高级的块放置和复制决定，但是必须要将Master对读和写的参与减至最少，这样它才不会成为系统的瓶颈，访问端从来不会从Master读和写文件数据，访问端只是询问Master它应该和哪个chunkserver联系，Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和chunkserver交互。

⑤块规模：块规模是设计中的一个关键参数，选择的是64K，64M两种，这比一般的文件系统的块规模要大的多，每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展(主要考虑文件的不同类型-大量都是小文件时，选择64K；否则选择64MB)。块规模较大的好处有：减少Client和Master之间的交互，因为读写同一个块只是要在开始时向Master请求块位置信息，对于读写大型文件这种减少尤为重要，即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的工作集缓存块位置信息；Client在一个给定的块上很可能执行多个操作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载；这减少了Master上保存的元数据(metadata)的规模，从而使得可以将metadata放在内存中。

⑥元数据(metadata)：Master存储了三种类型的metadata，文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位置，所有的metadata都放在内存中；前两种类型的metadata通过向操作日志登记修改而保持不变，操作日志存储在Master的本地磁盘并在几个远程机器上留有副本；使用日志使得我们可以很简单地、可靠地更新Master的状态，即使在Master崩溃的情况下也不会有不一致的问题；相反，Master在每次启动以及当有chunkserver加入的时候询问每个chunkserver的所拥有的块的情况。

A、内存数据结构

B、因为metadata存储在内存中，所以Master的操作很快；进一步，Master可以轻易而且高效地定期在后台扫描它的整个状态，这种定期地扫描被用于实现块垃圾收集、chunkserver出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。

C、这种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与Master的内存，Master为每个64MB的块维护的metadata不足96个字节，除了最后一块，文件所有的块都是满的；类似的，每个文件的名字空间数据也不足96个字节，因为文件名是以一种事先确定的压缩方式存储的。

D、块位置：Master并不为chunkserver所拥有的块的副本的保存一个不变的记录，它在启动时通过简单的查询来获得这些信息，Master可以保持这些信息的更新，因为它控制所有块的放置并通过HeartBeat消息来监控chunkserver的状态。

E、操作日志：操作日志包含了对metadata所作的修改的历史记录，它作为逻辑时间线定义了并发操作的执行顺序，文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识；Master可以用操作日志来恢复它的文件系统的状态，为了将启动时间减至最小，日志就必须要比较小，每当日志的长度增长到超过一定的规模后，Master就要检查它的状态，它可以从本地磁盘装入最近的检查点来恢复状态；创建一个检查点比较费时，Master的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改操作的方式来组织的，Master切换到一个新的日志文件并在一个单独的线程中创建检查点，这个新的检查点记录了切换前所有的修改，在一个有数十万文件的集群中用一分钟左右就能完成，创建完后，将它写入本地和远程的磁盘。

⑦数据完整性：名字空间的修改必须是原子性的，它们只能有Master处理，名字空间锁保证了操作的原子性和正确性，而Master的操作日志在全局范围内定义了这些操作的顺序；文件区间的状态在修改之后依赖于修改的类型，不论操作成功还是失败，也不论是不是并发操作，如果不论从哪个副本上读，所有的客户都看到同样的数据，那么文件的这个区域就是一致的；如果文件的区域是一致的并且用户可以看到修改操作所写的数据，那么它就是已定义的；如果修改是在没有并发写操作的影响下完成的，那么受影响的区域是已定义的，所有的访问端都能看到写的内容，成功的并发写操作是未定义但却是一致的，失败的修改将使区间处于不一致的状态。

Write操作在应用程序指定的偏移处写入数据，而record append操作使得数据(记录)即使在有并发修改操作的情况下也至少原子性的被加到BigFS指定的偏移处，偏移地址被返回给用户，在一系列成功的修改操作后，最后的修改操作保证文件区域是已定义的，BigFS通过对所有的副本执行同样顺序的修改操作并且使用块版本号检测过时的副本(由于chunkserver退出而导致丢失修改)来做到这一点；因为用户缓存了块位置信息，所以在更新缓存之前有可能从一个过时的副本中读取数据，但这有缓存的截止时间和文件的重新打开而受到限制。在修改操作成功后，部件故障仍可以使数据受到破坏，BigFS通过Master和chunkserver间定期的handshake，借助校验和来检测对数据的破坏，一旦检测到，就从一个有效的副本尽快重新存储，只有在BigFS检测前，所有的副本都失效，这个块才会丢失。

本层的技术实现主要包括以下内容：当某一应用在我们的云平台上访问一个文件时，最终必须顺着指针首先访问到目录映射的叶子节点，才能获得文件的实际存储信息；叶子节点存储着该文件的全部元数据，通过叶子节点的信息我们可以对存储在云系统分布式文件系统的文件进行访问和处理；在云计算系统中，对于非常大的文件往往会采用文件分块的方式进行存储，这些大文件会被系统按一定的策略分为若干个数据块，并将这若干个数据块存储于云系统的不同节点上，相关的存储系统会写入文件目录树中的某一个叶子节点中，为系统下次对该文件的操作提供信息，这些工作由文件系统中的文件数据分块及副本备份策略管理来完成，该层向目录树屏蔽具体的文件分块及副本策略，只是将最后的分配结果写入某一叶子节点中；前面的目录树并不会实际地存储文件，所有文件真正写入磁盘中是由文件数据分块及副本备份策略管理来完成的，只有执行了这一层的工作文件才会真正写入机群系统中完成文件的物理存储过程。

对于存储而言，通常一个文件由多个Chunk来存放，每个Chunk按64kbyte的大小分成块，重点考虑数据的一致性，每个块有32位的校验，在数据写入ChunkServer时，由ChunkServer计算出校验和，与数据分别存放；当读数据时，Chunkserver检查数据和校验和，校验错误，则通知应用和Master，从其它ChunkServer获取数据(校验可在Client完成)，并完成副本的重新创建；当主Master的元数据更改后，需要及时同步到备Master，实现双机备份，Master根据新的日志文件大小，对元数据进行备份，从内存中倒入本地硬盘，形成检查点；对于元数据的更改，Master都会产生日志文件，在硬盘进行保存，这样当系统崩溃后，Master可以根据备份元数据和检查点后的日志文件，对元数据进行快速恢复。

对于信息存储请求，系统根据信息的安全级别做不同数量的备份，对于一般应用不再做文件的分割，这样不但能提高数据的安全性，也为客户的数据访问提供并行的数据访问通道，文件的存储信息和元数据由云计算系统负责维护，并根据负载情况向用户分配服务器资源；安全级别高或并发访问要求高的文件将采用更多的节点对其进行副本备份，管理节点在用户访问请求提交后检查自己的文件存储信息，将其中一台存储有用户请求数据的服务器信息传递给用户，由用户直接访问该服务器并获得该服务器的计算和存储资源；由于同一个文件被存放在多个服务器上，不同的用户访问同一个文件时会根据负载情况被指引向不同的服务器，这样可以实现对文件访问的跨用户级并行数据传输；这一简化方案避免了文件分割和重组时的时间开销，由管理服务器来负责对系统进行协调，可以有效适应视频播放、游戏等应用的需要；对于一些特殊的应用需要计算向存储迁移时，本方案可由管理节点向用户返回所有存储有该数据副本服务器的信息，并协调各服务器对数据的不同部分进行分布式的处理。这一方案并不会增加对存储空间的要求。

本层要考虑到物理机器与虚拟机文件系统的物理位置的关系，包括位于同一物理机、同一交换机、同一机架、同一地理位置、不同物理位置的虚拟机的管理，node和交换机或者机架故障后的物理数量的合理分配、node的扩展和收缩等的管理都在本层实现；1+2备份和备份打散到不同机柜也是本层必须解决问题；物理机器的增加是在线进行的，这个涉及到均衡访问问题，使用Dynamo环技术来实现。

(3)基于表的结构云存储层(TBASE)：目前的云中的数据的特点是文件数量庞大，内容不停的append，或者文件数量不停地在增加，其保存的数据包括结构化数据和非结构化数据，结构化数据-数据库技术(根据行存储，支持事务和行锁-传统，分区技术是列技术与行技术的结合的一种过渡)。根据列存储-典型的根据时间、范围(地点)、id(-角色key)-地址(包括机群+组+机器+实例)--大表分行列切割存储在不同的机器，例如amuzo，部分支持事务；结构化数据-根据时间、范围(地点)、id(-角色key)利用云分布式文件(Bigfs)进行存储(不支持事务)

非结构化数据-流数据(例如视频流、备份数据流、email数据、网页等)--实际是分块的，这些块根据时间、范围(地点)、id(-角色key)以流方式存储的，例如视频流、网页、email、音频流、备份数据流(根据时间和文件集合分块)等；混合的数据(部分结构化数据+blob数据)，一般也包含时间、范围(地点)、id(-角色key)要素；数据存储和查找及计算：这些数据的内容存储在BigFS中，而这些内容根据根据文件名和关键字(时间、范围(地点)、id(-角色key))查找，如何在存储时根据关键字组织好存储node的目录结构，使得进行快速定位和查找，是本层的主要目的，与bigtable的技术类似。

我们在本层要实现的功能如下：支持多种数据结构，比如table、familie、group和coprocessor等(我们原来只支持时间、地点、关键字id)；基于分层目录和行的细粒度的复制和权限管理；支持跨数据中心的强一致性和弱一致性控制；基于Paxos算法的强一致性副本同步，并支持分布式事务；提供许多自动化操作；强大的扩展能力，能支持百万台服务器级别的集群；用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。

结构化数据以nosql和分布式数据库为主，根据key和时间及位置以文件形式存储，最好同一key的数据连接存储(考虑磁盘的读取要求和块读取性质)，其最终意义是一个根据数据的特点，自动建立根据数据特点的高效的并发的高可靠性的自动分析(或者智能计算)的技术。基于表的结构数据层提供大规模基于表格的结构数据管理；本层对应与传统文件系统的目录和fat(文件分配表)表，由于云存储的文件达到千万到几十亿(超大型)，这些文件有的是记录型的(结构型的)，有的是非结构型的，采用传统的数据库的技术无法解决问题，必须采用列存储的数据库技术、分区技术、memcache技术或者内存数据库技术、hash技术，本层根据规模可以分层子PART(类似oracle的分区，每个分区在不同的node)。

本层的可靠性非常关键，hadoop的hbase是单single-node，通过linux的DRDB技术实现双node，另外在中小规模时可以采用分布式的mysql内存数据库的Amoeba方式实现；另外本层的log应该计入数据节点，实现故障时的回滚和恢复(相当于数据库的redo和undo)，到数据层的备份位置移动和数据层的故障时，以及1+2备份的位置管理和登记在本层实现。

本层采用才分布式数据库和列数据库技术，系统的可扩展性非常好；由于是内网(云存储)，本层的安全性不是重点关注。

(4)流数据云存储层：本层对外部来的多个并发的数据流，进行分类排序和切割，并存储到队应的node，把存储的对象名对象的关键属性(可以嵌套，时间和区域及id为基本项目)存储在云存储结构数据层(TBASE)；基于高响应的内存流数据划分和分配是本层的主要任务，在读文件时，本层要并发访问多个node的数据流，实现分类排序(块)，把文件内容给用户层，考虑到性能，本层的存储的cache一般采用flash-cache(刚好利用flash-cache的特性)；本层必须采用多线程和多进程技术，实现分布式的平行存取处理；本层是多个实体机(合作虚拟机)，多进程技术和多线程技术在实现中必须采用。多线程是为了使得多个线程并行的工作以完成多项任务，以提高系统的效率，线程是在同一时间需要完成多项任务的时候被实现的，它允许在程序中并发执行多个指令流，每个指令流都称为一个线程，彼此间互相独立；线程又称为轻量级进程，它和进程一样拥有独立的执行控制，由操作系统负责调度，区别在于线程没有独立的存储空间，而是和所属进程中的其它线程共享一个存储空间，这使得线程间的通信远较进程简单；多个线程的执行是并发的，也就是在逻辑上“同时”，而不管是否是物理上的“同时”，如果系统只有一个CPU，那么真正的“同时”是不可能的，但是由于CPU的速度非常快，用户感觉不到其中的区别。使用线程的好处有以下几点：可以把占据长时间的程序中的任务放到后台去处理；用户界面可以更加吸引人，这样比如用户点击了一个按钮去触发某些事件的处理，可以弹出一个进度条来显示处理的进度；在一些等待的任务实现上如用户输入、文件读写和网络收发数据等，线程就比较有用。

本层的主要关注点有：本层最显著的特点就是高可靠性和高响应，本层可实现高速的基于热备份的出错恢复功能，本层是可以根据应用的需求不同可以扩展的，本层可以实现对上传信息流的过滤处理，加密处理，压缩处理，利用MD5码防止修改处理，实现系统的安全性。

(5)云存储安全访问接口层：本层实现ACL控制管理、用户管理、权限管理、配额管理、计费管理、CDMI标准接口API、和WEB-DAV接口访问、FTP和ftps接口访问、http和https接口访问等。

(6)云存储应用层：本层实现应用的功能，主要包括Map/reduce式的云计算应用(BI)、物联网数据管理、视频、移动互联网、企业云应用等，具体的有云存储的邮件系统、云存储的备份系统、云存储的在线同步系统、云存储的网络文件磁盘、云存储的物联网应用管理系统、云存储的移动信令分析系统、云存储的私有云平台系统、云存储的对OA的SaaS模式的改进的新的OA系统、云存储的电话详单查询系统、云存储的SMPP和CMPP的短信群发系统、云存储的身份证查询系统、云存储的货物跟踪系统、云存储的血液跟踪系统、云存储的宠物跟踪系统、云存储的电信机房系统等。其中的云存储的邮件系统：流文件为大数据流，每个流包含一个电子邮件的属性，这些属性存储在TBASE中，根据时间、主题、发件人、收件人集合和内容和附件(列)进行存储，云存储的备份系统流文件为大数据流，每个流包含一个文件集，这些属性存储在TBASE列中，根据角色(用户名)、时间戳、文件夹、文件名集合、文件内容的md5码为该集合的文件进行存储。

①云存储的在线同步系统：流文件为大数据流，每个流包含一个文件集，这些属性存储在TBASE中，根据角色(用户名)、时间戳、文件夹、文件名集合、文件内容的md5码为该集合的文件进行存储；

②云存储的物联网应用管理系统：流文件为大数据流，根据标签id、时间、地点(读头ID)存储在TBASE，文件内容为该标签范围的在指定时间的范围在什么位置，也就是没有truck的数据存储，全部存在TBASE；

③云存储的私有云平台系统：流文件为一定集合的不变的系统文件集合和变的文件集合，列包括OS名称和版本，文件集合的软件包名等；

④云存储的对OA的SaaS模式的改进的新的OA系统：：流文件为用户id和主题为列进行存储；

⑤云存储的电话详单查询系统：根据时间、地点、地区、费用名，0的内容列进行存储和指向指定套餐的基本费用做行集合；

⑥云存储的SMPP和CMPP的短信群发系统：根据通道号和时间及内容的MD5值对应的行号标识进行存储；

⑦云存储的身份证查询系统：TBASE根据身份证号码的地区和省及性别及有效期作为列，内容为身份号的其它部分和姓名和地址存储的。

本层采用的主要技术有：map-reduce是一种编程模型，用于大规模数据集(大于1TB)的并行运算，″Map(映射)″和″Reduce(化简)″的主要思想，都是从函数式编程语言和矢量编程语言里借来的特性，极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上；当前的软件实现是指定一个Map(映射)函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce(化简)函数，用来保证所有映射的键值对中的每一个共享相同的键组。Map-reduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性；每个节点会周期性的把完成的工作和状态的更新报告回来，如果一个节点保持沉默超过一个预设的时间间隔，主节点记录下这个节点状态为死亡，并把分配给这个节点的数据发到别的节点，每个操作使用命名文件的原子操作以确保不会发生并行线程间的冲突；当文件被改名的时候，系统可能会把他们复制到任务名以外的另一个名字上去。

云存储管理层主要实现对云存储层的管理，包括错误恢复、性能和错误检测、负载均衡、任务调度、进程调度、虚拟机管理等；主要采用的技术包括：机群监测，主要包括对错误、性能、负载、安全的监测，块、文件的备份管理，存储负载均衡，动态数据迁移，动态机群添加和恢复，基于Paxos协议的metadata可靠性，一致性管理等。

以上实施例是本发明较优选具体实施方式的一种，本领域技术人员在本技术方案范围内进行的通常变化和替换应包含在本发明的保护范围内。

Claims (2)

1.一种基于n×n陈列结构的云系统平台，其特征在于，对于硬件框架结构的实施主要包括以下：

(1)首先，直接通过网卡直连方式进行节点内服务器可靠通信，在系统应用层网络通信采用UDP直接通信，在应用层可靠性设计时利用其它n-1个节点进行并行计算或者通信，在复制文件时，先在本地节点把文件切块为n等分，然后通过多进程技术利用n条路由把文件从任何个节点copy到其它节点，并且采用RIAD5类型的海明校验技术，这些检验块在不同的节点中；

(2)然后，选择服务器安装LINUX操作系统，并且做root用户的互信，服务器之间的文件传输直接通过scp命令进行；

(3)同时，需要每个服务器建立一个/ULOC/IP地址/disk+逻辑磁盘编号的文件夹，通过SAMBA协议访问对应的物理机器磁盘文件，使用CIFS文件系统的主要目的使是linux和windows都可访问，并且是通过网络点到点通信访问的，CIFS协议的开销基本可以忽略不计；另外，若用户需要使用逻辑上只有一个目录的云存储，通过点到点通信结构配置MOOSEFS文件系统或者配置为iscsi设备，利用openfire在iscsi层实现从设备层对存储资源的逻辑上统一的访问；

(4)最后，机柜之间的通信采用在机柜的序号最大的节点加1万兆网卡，与下一个机柜的序号最小的机器加1万兆网卡的此网卡通信；

对于云存储层次结构的实施主要设置以下六个层次：

即本地或局域虚拟存储层和虚拟资源层、分布式高可靠性大文件云存储层、基于表的结构云存储层、流数据云存储层、云存储安全访问接口层、云存储应用层。

2.根据权利要求1所述的基于n×n陈列结构的云系统平台，其特征在于：对于本地或局域虚拟存储层和虚拟资源层，本地文件系统在大量小文件的应用时为ifs，否则用RaiseFS；网络文件采用SAMBA，该SAMBA用在可以共享windows为主机的windows系统的ntfs的本地磁盘和AIX小型机的本地磁盘。

Images