本申请涉及存储技术，特别涉及一种数据资源的存储方法。
背景技术：
目前，在计算机和通信技术领域中，各类项目在实施的过程中会发生如下情况：
一种情况是给用户来配置服务器硬盘容量时，都是按照最大的需求配置。然而现实中往往达不到这种峰值使用场景。这种情况下，不但给用户的前期投资带来损失，而且在后续的运营维护中增加了成本，比如机房的电力成本，大量磁盘的维护和折旧成本等；
另一种情况是在前期规划的时候没有充分考虑到未来应用增长的情况，造成后期存储资源紧缺；
还有一种情况是机房机柜等物理空间已经满配，没有多余的空间扩展存储资源。
以上的现实情况不仅给用户带来经济上的浪费，而且极大的增加了运维难度，甚至可能造成诸如系统终止等严重后果。
技术实现要素：
本申请提供一种数据资源的存储方法，能够在不浪费物理存储资源的前提下，方便地实现数据存储。
为实现上述目的，本申请采用如下技术方案：
一种数据资源的存储方法，包括：
a、资源使用设备上的应用通过与所述资源使用设备连接的客户端软件client向硬件资源共享服务器server请求进行数据存储；
b、所述server根据当前所有资源提供设备的可用资源状况，为所述应用预分配一个资源提供设备的硬件资源，并将预分配结果发送给与相应的资源提供设备相连的代理软件agent；
c、所述agent根据接收的预分配结果和与其相连的资源提供设备的当前负载状况，判断是否接受相应的预分配结果，并将判断结果反馈给所述server；
d、当所述判断结果为接受时，所述server通过所述client通知所述应用将数据存储在预分配的资源提供设备的指定资源上，所述应用将数据存储在所述预分配的资源提供设备的指定资源上，并通知所述client和所述server；所述client和所述server接收所述通知后，各自建立与所述应用对应的资源列表，并将所述预分配的资源提供设备及所述指定资源信息加入所述应用对应的资源列表；当所述判断结果为不接受时，重新执行步骤b、c、d；
其中，所述指定资源为分配给所述应用存储数据的硬件资源。
较佳地，该方法包括：当所述判断结果为接受时，所述agent分配用户名、密码和所述指定资源的访问路径，发送给所述server，并通过所述client转发给所述应用。
较佳地，当所述应用对应的资源列表建立完成后，该方法进一步包括：所述server根据备份策略选择n个资源提供设备，用于备份所述应用的数据，并将所述应用的数据备份到选择出的n个资源提供设备上；在备份完成后，将备份成功的资源提供设备及其存储资源的信息加入所述应用对应的资源列表，并通知所述client将备份成功的资源提供设备及其存储资源的信息加入所述client保存的与所述应用对应的资源列表；
其中，n为用户设定的冗余数，所述存储资源为用于存储所述应用的数据的硬件资源。
较佳地，当所述应用需要读取存储数据时，该方法进一步包括：
所述应用发送读取数据请求给所述client，所述client根据自身保存的所述应用对应的资源列表，选择一个保存所述应用数据的资源提供设备，并将选择的资源提供设备及其存储资源的信息反馈给所述应用，所述应用根据接收的信息访问所述选择的资源提供设备进行数据读取，并将读取结果反馈给所述client。
较佳地，所述选择一个保存所述应用数据的资源提供设备包括：在所述client保存的所述应用对应的资源列表中，选择一个访问路径最短的资源提供设备。
较佳地，当所述应用反馈给所述client的读取结果为读取失败时，该方法进一步包括：
所述client在自身保存的所述应用对应的资源列表中，重新选择一个资源提供设备，并将重新选择的资源提供设备的信息反馈给所述应用，并将发生读取失败的资源提供设备从自身保存的所述应用对应的资源列表中删除；所述应用根据接收的信息访问所述重新选择的资源提供设备进行数据读取，并将读取结果反馈给所述client；当所述应用读取数据成功后，所述client将所述发生读取失败的资源提供设备信息发送给所述server，所述server更新自身保存的所述应用对应的资源列表，并选择新的资源提供设备加入所述应用对应的资源列表，进行数据备份，在完成备份后更新所述server保存的所述应用对应的资源列表，并通知所述client更新其保存的资源列表。
较佳地，对于系统中的任一资源提供设备，该方法进一步包括：所述任一资源提供设备预先保存自身的配置信息，根据所述配置信息监测资源使用设备对自身资源的访问，并在发生异常时通知所述server；所述任一资源提供设备根据所述配置信息监测自身资源负载状况，并在发生异常时逐步释放备份属性的数据资源，若在备份属性的数据资源释放后仍然资源负载仍然异常，则释放所有分享资源，通知所述server，并关闭资源共享服务；所述任一资源提供设备根据所述配置信息监测连接服务，若发生异常则重建连接，并更新资源信息；
其中，所述配置信息包括以下至少一项：最大资源分享阈值、最大连接数、最大资源负载值、最大输入输出io负载值、资源负载权重和io负载权重。
较佳地，对于系统中的任一资源提供设备，该方法进一步包括：与所述任一资源提供设备相连的agent采集所述任一资源提供设备的io负载和磁盘空间负载，并计算负载值上报给所述server；
所述根据备份策略选择n个资源提供设备包括：所述server根据各个agent上报的负载值选择n个资源提供设备；
对于所述应用对应的资源列表中的各个资源提供设备，该方法进一步包括：所述server检测已分配资源存储的资源提供设备的负载，若负载异常，所述异常情况下的备份策略包括：所述server重新选择一个负载正常的资源提供设备，替换所述发生异常的资源提供设备，根据发生异常的资源提供设备所保存的数据，从保存相同数据的正常负载的资源提供设备上，将相应数据备份到所述重新选择的资源提供设备上，更新自身保存的资源列表，并通知所述相应数据所属资源使用设备的client更新其资源列表。
较佳地，所述server将所述应用的数据备份到所述选择出的n个资源提供设备上包括：
所述server从所述预分配的资源提供设备上或已完成备份的资源提供设备上，将所述应用的数据拷贝到未完成备份的其他资源提供设备上。
较佳地，所述agent计算负载值包括：负载值＝磁盘io权重*io负载+磁盘空间权重*磁盘空间负载；
所述选择n个资源提供设备包括：选择负载最低的n个资源提供设备。
由上述技术方案可见，本申请中，多个资源提供设备用于提供存储空间，资源使用设备的应用需要进行数据存储时，可以向服务器申请资源提供设备上的存储空间进行数据存储；由服务器向资源提供设备申请资源成功后，应用将数据存储在某资源提供设备上。通过上述方式，资源使用设备上的应用可以不在资源使用设备本地进行数据存储，可以将数据存储在其他资源提供设备上。这样，一方面对于资源使用设备不需要在前期投资时配置过大的硬盘资源，仍然能够保证资源使用设备上应用的数据存储需求。
附图说明
图1为本申请中基本存储系统的网络架构示意图；
图2为本申请中数据资源存储方法的基本流程示意图；
图3为实施例一中资源申请流程的示意图；
图4为实施例二中资源备份流程的示意图；
图5为实施例三中数据访问流程的示意图；
图6为实施例四中数据访问流程的示意图；
图7为本申请中资源列表的示例图；
图8为本申请中资源使用接口的示例图。
具体实施方式
为了使本申请的目的、技术手段和优点更加清楚明白，以下结合附图对本申请做进一步详细说明。
本申请的基本思想为：把多个空闲的硬盘资源整合成可分享的资源池，提高存储资源使用率。
其中，在上述基本思想的基础上，优选地，可以考虑实行如下需求，以更好地进行数据存储和管理：
1)资源提供设备自身需求最好不受影响，当自身需求受到影响时，可以选择自动释放已共享资源；
2)可以通过冗余备份机制将资源使用设备上的数据备份到多个资源提供设备上，以确保资源使用设备的资源使用安全可靠；
3)通过资源分配策略确保资源使用设备的资源访问高效；
4)通过用户权限管理确保对资源提供设备的共享资源访问安全可靠；
6)系统设计与硬件无关。
本申请的基本存储系统网络架构包括：资源使用设备上的应用程序、客户端软件(client)、硬件资源共享服务器(server)、代理软件(agent)、资源提供设备上的硬盘资源。整个资源平台采用client/server/agent三级模式，使用灵活，耦合性低。系统网络架构示意图如图1所示。下面分别介绍系统架构的各个组成部分。
资源使用设备上的应用程序：作为资源的借用者，该应用程序调用client提供的接口与资源共享平台建立连接，从而实现存储资源的申请、释放等功能。
client：client模块与资源使用设备部署在相同位置，一方面与资源使用设备对接，另一方面与资源平台server模块对接，完成资源借用者的资源申请、资源释放等指令的透传功能。
server：作为资源共享平台的核心控制中心，负责整合资源使用设备、资源提供设备等相关资源。通过资源负载算法、资源备份策略、资源分配策略等方法确保系统的合理、高效，稳定、可靠的运行。
agent：agent模块与资源提供者部署在相同位置。负责资源提供者的资源计算、资源保护、资源共享、资源释放等功能。
资源提供设备上的硬盘资源：硬盘存储资源。
图2为本申请中数据资源存储方法的基本流程示意图。如图1和图2所示，该基本流程包括：
步骤201，资源使用设备上的应用通过与资源使用设备连接的client向server请求进行数据存储；
步骤202，server根据当前所有资源提供设备的可用资源状况，为应用预分配一个资源提供设备的硬件资源，并将预分配结果发送给与相应的资源提供设备相连的agent；
步骤203，agent根据接收的预分配结果和与其相连的资源提供设备的当前负载状况，判断是否接受相应的预分配结果，并将判断结果反馈给server；当agent反馈的判断结果为接受时，执行步骤204，否则，重新执行步骤202-203；
步骤204，server通过client通知应用将数据存储在预分配的资源提供设备的指定资源上，应用将数据存储在预分配的资源提供设备的指定资源上，并通知client和server；
其中，指定资源为分配给应用存储数据的硬件资源。
步骤205，client和server接收到应用数据已存储的通知后，各自建立与应用对应的资源列表，并将预分配的资源提供设备及其指定资源信息加入应用对应的资源列表。
至此，本申请中最基本的数据资源存储方法流程结束。上述流程实际上对应的是存储资源的申请过程。除对于存储资源的申请外，还可以基于该系统结构进行存储数据的访问、存储数据的备份、以及资源提供设备的状态监控等。接下来，通过几个具体实施例详细说明上述流程。
实施例一：
图3为实施例一中资源申请流程的示意图。如图3所示，该流程具体包括：
步骤301，资源使用设备、client、server、agent建立连接。
步骤302，资源使用设备发送申请资源请求给client，client透传该请求给server。
步骤303，server选择一个资源提供设备预分配资源，并在预分配资源后向与选择的资源提供设备相连的agent发送资源请求消息。
其中，预分配资源包括：server在各个提供硬件资源共享的资源提供设备中选择一个资源提供设备。选择的资源提供设备应当能够满足应用的数据存储需求。
步骤304，agent收到资源请求消息，计算与其相连的资源提供设备可分享的存储资源，如果同意预分配，则分配存储资源(以下称为指定资源)，并分配用户名、密码和指定资源的访问路径，并将相关信息返回server，执行步骤306；如果不同意分配，则通知server预分配失败，执行步骤305。
步骤305，server收到agent返回的资源信息，重新执行步骤303-304。
步骤306，server收到agent返回的资源信息，转发给client，client再转发给资源使用设备上的应用。
步骤307，资源使用设备上的应用收到资源信息后，通过ftp方式将数据文件上传至资源提供设备的指定资源上。
步骤308，资源使用设备上传完文件之后，发送文件传输完毕通知给client，client再传送给server。
步骤309，server和client收到文件传输完毕通知后，建立与应用对应的资源列表，并将存储成功的资源使用设备及其指定资源信息加入与应用对应的资源列表。
至此，资源申请的具体流程结束。
实施例二：
本实施例用于说明资源使用设备上应用数据的备份存储方式，以保证应用数据的存储安全。图4为实施例二中资源备份流程的示意图，优选地，该流程在server收到资源使用设备发送的文件传送完毕消息之后开始进行。如图4所示，该流程具体包括：
步骤401，server根据备份策略选择n个资源提供设备，用于备份应用的数据，并将应用的数据备份到选择出的n个资源提供设备上。
其中，n可以是用户设定的冗余数。优选地，每个与资源提供设备相连的agent会采集相应资源提供设备的io负载和磁盘空间负载，并计算负载值上报给server。计算负载的方式可以为：负载＝磁盘io权重*io负载值+磁盘空间权重*磁盘空间负载值，磁盘io权重和磁盘空间权重可以根据需要预先设定。server可以根据各个agent上报的负载值选择用于备份数据的n个资源提供设备。具体地，可以选择负载最低的n个资源提供设备，用于进行数据备份。
另外，在备份应用数据时，可以将资源使用设备上应用传输的数据，从资源提供设备的存储资源上拷贝到根据备份策略选择出的其他资源提供设备处。或者，还可以资源使用设备上应用传输的数据，从已经完成备份的资源提供设备上拷贝到未完成备份的资源提供设备上，例如，从设备a拷贝到备份设备b，再从备份设备b拷贝到备份设备c，从备份设备c拷贝到备份设备d等，这种拷贝方式，可以避免短时间内对于同一个资源提供设备的反复访问。
步骤402，在备份完成后，server将备份成功的资源提供设备及其存储资源的信息加入应用对应的资源列表。
其中，存储资源为本次用于存储相应应用数据的硬件资源。server上保存的与应用对应的资源列表更新后，即包括所有存储该应用数据的资源提供设备及存储资源的信息。
步骤403，server通知client将备份成功的资源提供设备及其存储资源的信息加入client保存的与应用对应的资源列表。
与server上保存的资源列表相同地，client保存的资源列表也进行更新，从而能够包括所有存储相应应用数据的资源提供设备及存储资源的信息。
上述备份处理过程为正常情况下的备份策略流程。如果server根据agent上报的资源提供设备的负载等信息或根据资源使用设备的应用反馈的资源提供设备工作异常的信息确定出某资源提供设备出现异常，则需要执行异常情况下的备份策略流程，具体包括：
server根据收到的信息判断出某资源提供设备异常后，重新选择资源提供设备，用于替换出现异常的资源提供设备。server执行备份策略，将保存相同应用数据的正常的资源提供设备上保存的应用数据，备份到新增加的资源提供设备上，更新自身保存的与应用对应的资源列表，并通知client同步更新与应用对应的资源列表。client更新资源列表。
实施例三：
本实施例用于说明资源使用设备上的应用对资源提供设备上存储数据的访问。图5为实施例三中数据访问流程的示意图，优选地，该流程在server完成应用数据的在资源提供设备上的存储和备份、并在server和client完成资源列表更新后开始进行。如图5所示，该流程具体包括：
步骤501，资源使用设备上的应用、client、server、agent建立连接。
步骤502，资源使用设备上的应用发送读取资源请求给client。
步骤503，client收到资源读取请求后，读取资源列表，从中选择一个合适的资源提供设备。
优选地，可以选择一个访问路径最短的资源提供设备。
步骤504，client将选定的资源提供设备的访问信息返回给资源使用设备上的应用。
其中反馈的信息用于对资源提供设备上的存储的该应用数据进行访问，具体可以包括用户名、密码、存储资源的访问路径等。这里，一个资源提供设备上可能存储有多个不同应用的数据，这些应用可能属于相同的资源使用设备，也可能属于不同的资源使用设备，因此，本步骤返回的应当是与提出请求相关的存储资源的访问信息。
步骤505，资源使用设备上的应用从资源提供设备上读取数据，并将读取结果告知client。若资源访问成功，则结束本流程。若资源访问失败，则执行步骤406。
步骤506，client收到访问失败的信息后，从资源列表中重新选择一个资源提供设备，将该设备的信息返回给资源使用设备上的应用，并将上一个访问失败的资源提供设备从资源列表中删除。
步骤507，资源使用设备上的应用从新分配的资源提供设备处处读取文件，并将结果告知client，若访问成功，则执行步骤408，否则返回步骤406。
步骤508，client收到读取成功的信息后，将之前访问失败的资源提供设备的信息发送至server。
步骤509，server将访问失败的资源提供设备及其存储资源信息从与应用对应的资源列表中删除，选择新的资源提供设备加入相应的资源列表，并执行备份策略。
这里执行备份策略，即将应用数据存储到新选择的资源提供设备上。
步骤510，server执行完备份策略，更新与应用对应的资源列表，并将资源列表信息发送至client。
步骤511，client收到信息后，更新资源列表，将新增的资源提供设备及其存储资源信息加入资源列表。
实施例四：
本实施例用于说明资源提供设备的自我保护流程。图6为实施例四中数据访问流程的示意图。如图6所示，该流程具体包括：
步骤601，资源提供设备启动，并配置相关信息。
其中，相关信息可以包括：最大资源分享阈值、最大连接数、最大资源负载值、最大io负载值、资源负载权重、io负载权重等。
步骤602，执行监控应用数据状况的服务。
具体地，可以判断数据是否被第三方访问，如果正常的话就继续执行监控服务。如果数据出现异常，则通知server数据异常信息。
步骤603，执行监控资源提供设备自身状况的服务。
其中，具体监控服务具体包括：一方面判断资源连接状况，如果正常的话继续监控，如果异常的话，后续拒绝资源使用申请；另一方面判断资源负载状况，如果正常的话继续监控，如果异常的话，逐步释放备份属性的数据资源，并再次判断资源负载状况。如果负载继续超标的话，则释放全部分享资源，通知server更新资源列表，并关闭资源共享服务。
步骤604，执行状态连接判断服务，判断连接状况，如果正常的话继续监控，如果异常的话重新建立连接，并更新资源信息。
上述即为本申请中资源存储方法的具体实现。接下来给出一个资源列表的示例，如图7所示，该资源列表包括以下组成部分：
1.索引关键字：资源使用设备的应用程序名称作为索引，字段长度30
2.时间戳：资源使用设备的应用上传完文件的时间，字段长度30
3.资源使用设备ip地址：资源使用设备ip地址，字段长度20
4.资源文件名称：资源文件名称，字段长度100
5.资源文件大小：资源文件长度，字段长度20
6.资源提供设备ip地址：资源提供设备ip地址，字段长度20
7.用户名：ftp访问路径的用户名，字段长度为30
8.密码：ftp访问路径的密码，字段长度为100
9.ftp路径：共享资源ftp访问路径，字段长度为10
10.优先级：资源提供设备优先级，字段长度10
11.故障标记：资源提供设备故障标价，字段长度5
12.负载权重：资源提供设备负载权重，字段长度10
资源使用接口给出如图8所示的示例。其中包括：
1.connect()：资源使用设备上的应用连接到资源平台client模块。
2.disconnect()：资源使用设备上的应用断开与资源平台client模块的连接。
3.bookresource()：资源使用设备上的应用申请使用资源。资源平台返回资源信息。
4.releaseresource()：资源使用设备上的应用释放资源。
5.setflag()：资源使用设备上的应用通知资源平台，资源使用情况。
6.write()：资源使用设备上的应用写入数据文件。
7.read()：资源使用设备上的应用读取数据文件。
8.remove()：资源使用设备上的应用删除数据文件。
当然，具体资源使用接口可以不限于上述提供的接口方式。
通过上述本申请提供的资源存储方法，改变了传统项目实施中用高配物理存储应对峰值需求的不足之处。利用现存空闲存储资源，解决某些存储需求不足的问题。采用client/server/agent三级软件架构模式，耦合性低。利用负载计算空闲资源的优先级，并利用负载及冗余粒度进行文件备份，同时能够对资源提供设备进行自动保护，确保资源提供设备自身应用程序不受影响。极大的降低了用户的固定投资以及运维费用，进一步实现了节能环保的目标。对资源提供设备来说是透明的，不会产生任何影响，应用方便。对资源使用设备上的应用来说耦合性低，只需调用简单的几个接口即可。通过各种策略设计确保了用户使用的安全可靠。数据文件的写入是一次性写入，降低长连接的使用频率，提高了数据访问效率。与硬件设备无关，不需要额外增加硬件成本。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。