云硬盘资源的回收方法及相关装置与流程

本发明涉及计算机技术领域，具体涉及云硬盘资源的回收方法及相关装置。

背景技术：

云平台可为用户提供云计算、云存储等基于互联网的相关服务，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。

云平台使用虚拟机(云服务器)面向使用者提供服务。使用者可向云平台提交申请创建云服务器，云平台选择宿主机(host)，在该宿主机上创建云服务器，并依据使用者的需求向后端存储集群申请创建一个或多个云硬盘。

云硬盘是一种基于分布式存储架构，可弹性扩展的虚拟块存储设备。宿主机和后端存储集群可通过open-iscsi等协议通讯，将虚拟块设备(即云硬盘)映射到宿主机上。云硬盘映射到宿主机上，需要向宿主机申请一定的资源(云硬盘资源)，例如盘符、块设备号以及内存资源(用于存储会话、描述信息等信息)。

在需要回收云硬盘时(例如使用者对云服务器的租用到期，需要回收云服务器和云硬盘，或者需要恢复宿主机环境)，宿主机可通过与后端存储集群之间的通讯，来分别回收宿主机侧的云硬盘资源和后端存储集群侧的云硬盘资源。

但在一些特殊场合下，宿主机侧的云硬盘资源可能会回收失败，原因例如可能是：因宿主机自身系统原因或网络原因导致宿主机与后端存储集群之间的通讯失败，进而导致宿主机侧的云硬盘资源回收失败。

这样，宿主侧本应被回收却未被回收的云硬盘(可称为残留云硬盘)对应的云硬盘资源(脏数据)无法释放，将会占用宿主机的内存。因此，云硬盘资源的回收方式有待优化。

技术实现要素：

有鉴于此，本发明实施例提供云硬盘资源的回收方法及相关装置，以优化云硬盘资源的回收方式。

为实现上述目的，本发明实施例提供如下技术方案：

一种云硬盘资源的回收方法，应用于宿主机，所述宿主机与多个云硬盘存在映射关系，所述云硬盘资源回收方法包括：

接收云硬盘回收命令，所述云硬盘回收命令中包含操作方式和操作对象，所述操作方式用于表征回收云硬盘，所述操作对象包括需回收的云硬盘的标识；

解析所述云硬盘回收命令，获取所述需回收的云硬盘的标识；

判断是否满足强制回收条件；

在判定满足所述强制回收条件时，对宿主机侧与所述云硬盘的标识相关联的云硬盘资源进行强制回收。

一种云硬盘资源的回收装置，包括接收单元和强制回收单元，其中：

所述接收单元用于：接收云硬盘回收命令，所述云硬盘回收命令中包含操作方式和操作对象，所述操作方式用于表征回收云硬盘，所述操作对象包括需回收的云硬盘的标识；

解析所述云硬盘回收命令，获取所述需回收的云硬盘的标识；

所述强制回收单元用于判断是否满足强制回收条件；

在判定满足所述强制回收条件时，对宿主机侧与所述云硬盘的标识相关联的云硬盘资源进行强制回收。

一种终端，包括上述的回收装置。

在本发明实施例中，在接收云硬盘回收命令(包括需回收的云硬盘的标识)后，在判定满足强制回收条件时，会对宿主机侧与云硬盘的标识相关联的云硬盘资源进行强制回收。上述强制回收过程不依赖与后端存储集群的通讯。通过本发明实施例所提供的方案，可提高宿主机侧云硬盘资源回收的成功率，优化了云硬盘资源的回收方式。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1a和1b为本发明实施例提供的应用场景示例图；

图2为本发明实施例提供的终端的计算机架构示例图；

图3-图8为本发明实施例提供的回收方法的示例性流程图；

图9为本发明实施例提供的回收装置的示例性结构图。

具体实施方式

本发明提供云硬盘资源的回收方法及相关装置(例如回收装置、终端)。

上述回收装置可以软件的形式应用于上述终端中，或以硬件(例如具体可为终端的控制器/处理器)的形式作为上述宿主机的组成部分。

当以软件形式存在时，上述回收装置具体可为一进程，也可作为某应用程序或操作系统的组件。

图1a和图1b示出了上述回收装置的一种示例性应用场景(云平台)，其可包括多个作为宿主机(host)的终端和后端存储集群。

其中，上述后端存储集群进一步包括至少一个存储控制器，存储控制器可以连接多个(例如12个)物理磁盘，每一物理磁盘的存储空间可为2T或者更多。所有与存储控制器连接的磁盘的存储资源构成一个存储池。

存储控制器主要负责计算和分配存储池中的存储资源。

使用者可向云平台的云管理模块(未示出)提交申请创建云服务器，云管理模块根据一定的策略选择宿主机，在该宿主机上创建为上述使用者服务的云服务器(虚拟机)，每个虚拟机都具有处理器、内存、网络连接和存储，可以运行各自的操作系统和应用程序。

此外，云管理模块可向后端存储集群申请创建一个或多个云硬盘。

后端存储集群中的存储控制器可通过open-iscsi等协议通讯，将虚拟块设备(即云硬盘)映射到上述宿主机上。

open-iscsi属于端到端的会话层协议。open-iscsi协议通过登录(login)过程创建宿主机与存储控制器之间的新会话或重新创建会话，一个云硬盘对应一个会话。

云硬盘映射到宿主机上，需要向宿主机申请一定的资源(云硬盘资源)，例如盘符、块设备号以及内存资源(用于存储会话、描述信息等信息)。

之后，由宿主机负责分配云硬盘给云服务器。云硬盘可作为云服务器的系统盘或数据盘：在作为系统盘时，可用于存放虚拟机的操作系统(guest)，在作为数据盘时，可用于存放使用者的业务数据。

此外，仍请参见图1a，云平台还可包括监控系统(包括一个或多个监控服务器)、迁移系统(可包括一个或多个迁移服务器)和回收系统(可包括一个或多个回收服务器)。其中：

监控系统可用于监控一个或多个宿主机是否出现故障。在宿主机出现故障时，通知迁移系统将出现故障的宿主机上的虚拟机(即云服务器)迁移到新宿主机上。迁移成功，迁移系统可通知回收系统回收原宿主机上的云服务器及相关联的云硬盘。

此外，回收系统也可在云服务器的租用期到期后，回收宿主机上的云服务器及相关联的云硬盘(例如，用户购买了一个月的云服务器，到一个月时，需要回收云服务器和云硬盘)，或者，回收系统可在判断需要恢复宿主机环境时，发起对云硬盘的回收。另外，也可人工触发回收系统回收云硬盘。

图2示出了上述宿主机的一种通用计算机系统结构。

上述计算机系统可包括总线、处理器1、存储器2、通信接口3、输入设备4和输出设备5。处理器1、存储器2、通信接口3、输入设备4和输出设备5通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个挂件之间传送信息。

处理器1可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(Network Processor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

处理器1可包括主处理器(CPU)，还可包括显卡中的图形处理器(GPU)等。

处理器1的个数可为一个或多个。

存储器2中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，存储器2可以包括只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。

输入设备4可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏、计步器或重力感应器等。

输出设备5可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口3可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。

处理器1通过执行存储器2中所存放的程序以及调用其他设备，可实现图3-图8所示实施例提供的回收方法。

前已述及，在现有回收方式中，宿主机可通过与后端存储集群之间的通讯，来分别回收宿主机侧的云硬盘资源和后端存储集群侧的云硬盘资源。

请参见图3，在现有方式中，如果宿主机A想要解除云硬盘Y与自身的映射关系，其需要做如下处理：

S300：接收云硬盘回收命令；

S301：检查是否满足卸载条件，若是，进入S302，否则进入S307；

如下三个条件(情况)满足其中一个，都不满足卸载条件：

(1)，正在针对云硬盘Y执行登录(login)过程，包括创建新会话和重新建立会话；

(2)，正在针对云硬盘Y执行登出(logout)过程；

(3)，open-iscsi服务重启后，会依次同步(sync)当前已经挂载到宿主机的云硬盘，若正在针对云硬盘Y执行同步过程，也是不允许卸载的。

S302：向提供虚拟块设备(云硬盘Y)的后端存储集群中的存储控制器发送logout命令，通知后端存储集群即将结束会话，准备在后端存储集群侧回收云硬盘Y相关联的云硬盘资源；

之后，若后端存储集群回收成功，则返回表征回收成功的消息，否则返回表征回收失败的消息。

S303:判断logout命令是否执行成功，若是，进入S304，否则进入S307；

可通过后端存储集群返回的消息予以判断。

S304：回收云硬盘Y挂载时向宿主机申请的资源，包括盘符、块设备号、以及维护会话和连接等结构的内存资源；

S305：判断是否回收成功，若是，进入S306，否则进入S307；

各资源都有对应的存储地址，可通过访问相应的存储地址，来判断是否存储地址的数据已清除或被无效掉，若已清除或被无效掉，则判定回收成功，否则判定回收失败。

S306：云硬盘成功从宿主机卸载(宿主机侧的云硬盘资源回收成功)；

S307：云硬盘从宿主机卸载失败(宿主机侧的云硬盘资源回收失败)。

考虑以下特殊情况：

情况一，宿主机(为便于说明，可称呼其为宿主机A)无法与存储控制器通讯，但此时，需要回收宿主机上的云服务器及相关联的云硬盘(为便于说明，可称呼其为云硬盘Y)，或需要回收云硬盘Y；

情况二，存储控制器强制解除宿主机A与云硬盘Y间的映射关系。

强制解除的原因可能是：宿主机A出现故障，迁移系统将云服务器迁移到新的宿主机(宿主机B)上，在迁移成功后，迁移系统通知存储控制器强制解除宿主机A与云硬盘Y间的映射关系；

或者，在无法与故障的宿主机A通讯的情况下，存储控制器强制解除云硬盘Y与宿主机A间的映射关系。

无论出现哪某种情况，从存储控制器的角度而言，宿主机A已不具有读写云硬盘Y的权限。但对于宿主机A而言，其上还残留着云硬盘Y的资源信息。

若存储控制器强制解除宿主机A与云硬盘Y间的映射关系后，宿主机A向存储控制器发送logout命令以期望回收云硬盘资源，则由于在存储控制器侧宿主机A已不具备读写云硬盘Y的权限，则存储控制器会向宿主机A返回表征回收失败的消息，在接收到表征回收失败的消息后，宿主机A侧的执行步骤将跳转至S307，从而无法完成回收。

或者，在存储控制器已强制解除云硬盘Y与宿主机A间的映射关系后，宿主机A故障恢复，并重启了open-iscsi服务，open-iscsi服务会同步(sync)当前已经挂载到宿主机的磁盘。而由于宿主机A还残留着云硬盘Y的资源信息，则也需对云硬盘Y进行同步。当然，同步不会成功，则按照open-iscsi的机制，会一直尝试对云硬盘Y进行同步，这会导致无法满足卸载条件，无法发送logout命令，则宿主机A侧的执行步骤也将跳转至S307，同样无法完成回收。

此外，需要说明的是，除了占用内存资源外，残留云硬盘还可能对当前正常挂载在宿主机A上的其他云硬盘造成严重影响。这是因为：若残留云硬盘同步顺序排在其他正常挂载的云硬盘之前，则会因残留云硬盘无法完成同步，而导致其他的云硬盘也无法完成同步。

目前只有通过重启宿主机的方式，才能彻底清除残留云硬盘。而对于正运行在当前宿主机上的云服务器，在重启宿主机前，要么关机停止服务，或者热迁移到其它宿主机上，综合来看，通过重启宿主机方式来清除残留云硬盘的成本太高。

可见，现有云硬盘资源的回收方式需要优化。

图4示出了上述云硬盘资源的回收方法的一种示例性流程，以实现云硬盘资源回收的优化。

图4所示的方法应用于上述提及的领域或应用场景(例如图1a和图1b)中，由图2所示的宿主机中的处理器1与其他部件交互完成。

上述示例性流程包括：

在400部分：接收并解析云硬盘回收命令。

上述云硬盘回收命令可由回收系统发送。更具体的，回收系统可在迁移系统的通知下发送云硬盘回收命令。或者，回收系统也可在云服务器的租用期到期后或判断需要恢复宿主机环境时发送云硬盘回收命令。

上述云硬盘回收命令中可包含操作方式和操作对象，其中，操作方式用于表征回收云硬盘，而操作对象包括需回收的云硬盘的标识(ID)。更具体的，云硬盘的ID可为块设备号。

通常，一条命令(指令)中包含操作符和操作数。操作数是指令执行的参与者，也就是各种操作对象，与之有关的是操作符，操作符用于表征计算机要执行哪种操作，例如传送、运算、移位、跳转等，是指令中不可缺少的组成部分。

相应的，上述操作方式可由一个或多个操作符来表征。而云硬盘的标识则是操作数。

在401部分：判断是否满足强制回收条件；若是，进入402部分；

更具体的，上述强制回收条件包括：非强制云硬盘回收失败，卸载条件不满足，以及，上述操作方式具体用于表征强制回收云硬盘中的至少一种。

其中，当下述三种情况中的任一种情况发生时，判定卸载条件不满足：

正在针对上述需回收的云硬盘执行登录操作；

正在针对上述需回收的云硬盘执行登出操作；

正在针对上述需回收的云硬盘执行同步操作。

相关介绍请参见前述S301的记载，在此不作赘述。

在402部分：对宿主机侧与云硬盘的标识相关联的云硬盘资源进行强制回收。

以云硬盘Y为例，在满足强制回收条件时，会对其在宿主机侧的云硬盘资源(盘符、块设备号、以及维护会话和连接等结构的内存资源)进行强制回收。

在一个示例中，若不满足强制回收条件，可进行非强制云硬盘回收。非强制云硬盘回收可参见现有的回收方式。

需要说明的是，在现有的回收方式中，需要宿主机和后端存储集群之间进行通讯，并在满足卸载条件时，才可进行回收。

而强制回收则可不跟后端存储集群通讯，甚至不管卸载条件是否满足，而进行回收。

可见，在本发明实施例中，在接收云硬盘回收命令(包括需回收的云硬盘的标识)后，在判定满足强制回收条件时，会对宿主机侧与云硬盘的标识相关联的云硬盘资源进行强制回收。上述强制回收过程不依赖与后端存储集群的通讯(不必发送logout命令)。通过本发明实施例所提供的方案，可提高宿主机侧云硬盘资源回收的成功率，优化了云硬盘资源的回收方式。

下面将针对强制回收条件的不同组合，进行更为详细的说明。

图5示出了上述云硬盘资源的回收方法的另一种示例性流程，包括：

在500部分:宿主机(中的处理器1)接收并解析云硬盘回收命令。

在本实施例中，上述云硬盘回收命令中的操作方式用于表征强制回收云硬盘。

更具体的，可由两个操作符来表征操作方式为强制回收云硬盘，其中一个操作符用于表征回收，另一个操作符用于表征类型为强制。

也可以认为，接收的是云硬盘强制回收命令。

其他相关细节请参见前述实施例的400部分，在此不作赘述。

在501部分：宿主机(中的处理器1)根据操作方式确定需要强制回收，进入502部分；

也即，在本实施例中，强制回收条件包括：操作方式具体用于表征强制回收云硬盘。

在502部分：宿主机(中的处理器1)对宿主机侧与云硬盘的标识相关联的云硬盘资源进行强制回收。

502部分与前述实施例的402部分相类似，在此不作赘述。

在本发明实施例中，在接收到云硬盘强制回收命令(包括云硬盘的标识)后，会直接强制回收宿主机侧与云硬盘的标识相关联的云硬盘资源。此种方式实现起来较为简单，效率相对较高。

图6示出了云硬盘资源的回收方法的又一种示例性流程，包括：

在600部分:宿主机(中的处理器1)接收并解析云硬盘回收命令。

600部分与400部分相类似，在此不作赘述。

需要注意的是，在本实施例中，上述云硬盘回收命令中的操作方式可用于表征强制回收云硬盘或用于表征回收云硬盘。

在601部分:宿主机(中的处理器1)进行非强制云硬盘回收。

也即，在本实施例中，先进行非强制云硬盘回收，后续可根据情况进行强制云硬盘回收。

非强制云硬盘回收的方式可参见前述的300-307部分，在此不作赘述。

在602部分：宿主机(中的处理器1)判断非强制云硬盘回收是否失败，若是，进入603部分。

如何判断是否回收成功可参见前述305部分的介绍，在此不作赘述。

也即，在本实施例中，强制回收条件包括：强制云硬盘回收失败，或者，强制云硬盘回收失败并且操作方式具体用于表征强制回收云硬盘。

在603部分：宿主机(中的处理器1)对宿主机侧与云硬盘的标识相关联的云硬盘资源进行强制回收。

603部分与前述实施例的402部分、502相同，在此不作赘述。

可见，在本实施例中，先进行非强制云硬盘回收，如果非强制云硬盘回收执行成功，在宿主机侧和后端存储集群都不会存在脏数据信息。若非强制云硬盘回收执行不成功，则可进行强制云硬盘回收，保证宿主机侧不会存在脏数据信息。

图7示出了上述云硬盘资源的回收方法的又一种示例性流程，包括：

在700部分:宿主机(中的处理器1)接收来自回收系统的第一云硬盘回收命令，并解析。

需要注意的是，在700部分，第一云硬盘回收命令中的操作方式用于表征非强制性回收云硬盘。

其他细节请参见本文前述400部分的介绍，在此不作赘述。

在701部分:宿主机(中的处理器1)进行非强制云硬盘回收。

非强制云硬盘回收的方式可参见前述的300-307部分，在此不作赘述。

在702部分：宿主机(中的处理器1)判断非强制云硬盘回收是否失败，若是，进入703部分。

如何判断是否回收成功可参见前述305部分的介绍，在此不作赘述。

在703部分：向回收系统返回表征回收失败的消息。

当然，若在702部分判断回收成功，则向回收系统返回表征回收成功的消息。

在704部分：宿主机(中的处理器1)接收来自回收系统的第二云硬盘回收命令，并解析。

需要注意的是，在704部分，第二云硬盘回收命令中的操作方式用于表征强制性回收云硬盘。

在705部分：宿主机(中的处理器1)对宿主机侧与云硬盘的标识相关联的云硬盘资源进行强制回收。

705部分与前述实施例的603部分、502部分、402部分相同，在此不作赘述。

在706部分：宿主机(中的处理器1)判断强制云硬盘回收是否成功，若是，向回收系统返回表征回收成功的消息，否则，向回收系统返回表征回收失败的消息。

在本实施例中，是由回收系统判断是进行非强制回收还是强制回收的，这样可减轻宿主机的系统负担。

宿主机的操作系统一般为Linux。Linux操作系统分为用户层和内核层，在用户层为云硬盘分配了内存资源，其中，用户层的内存资源主要用于存储云硬盘的描述信息、会话信息等；内核层为云硬盘分配盘符、块设备号，此外，内核层也会保存会话信息。

open-iscsi服务在用户层有两个进程，一个是接收管理命令的进程(可称为接收进程)，可接收选项(即操作符)和参数(操作数)。也即，接收进程是暴露给宿主机上其他进程的接口；另一个是守护进程iscsid，守护进程为常驻进程。

接收进程在接收到云硬盘回收命令后，会通知守护进程iscsid云硬盘的标识和操作符，守护进程可调用相应的代码进行云硬盘资源的回收。

需要说明的是，为了实现强制回收，可在open-iscsi的代码中添加一段用于强制回收云硬盘资源的代码。守护进程iscsid可调用强制回收云硬盘资源的代码，根据云硬盘的标识进行强制回收。而非强制云硬盘回收是另一段代码，通过调用该段代码，可执行非强制云硬盘回收。

此外，守护进程也可用于判断是否满足强制回收条件。

基于上述接收进程和守护进程，图8示出了云硬盘资源的回收方法的又一示例性交互流程，包括：

在800部分:回收系统向宿主机发送清除云服务器和云硬盘的管理命令。

回收系统可在云服务器的租用期到期后，主动向宿主机发送清除云服务器和云硬盘的管理命令。

当然，也可人为触发回收系统向宿主机发送管理命令。

管理命令中可包含操作方式和操作对象，相关介绍请参见400部分的介绍，在此不作赘述。

其中，操作对象包括云服务器标识和云硬盘的标识，云服务器和云硬盘可对于一个操作方式(例如回收)，也可对应两个操作方式，例如云服务器标识对应的操作方式为回收，而云硬盘标识对应的操作方式可为强制回收。

在801部分：宿主机的命令接收进程或模块接收并解析管理命令。

宿主机有专门的接收命令的进程或模块接收并解析管理命令。

需要注意的是，宿主机接收命令的进程与open-iscsi服务在用户层的接收管理命令的进程不是同一个进程。

在802部分：宿主机的管理模块(具有清除云服务器功能)清除管理命令中指定的云服务器。

更具体的，宿主机接收命令的进程或模块通知宿主机的管理模块对指定的云服务器进行回收，主要是清除为云服务器分配的各种资源。

在803部分：宿主机的管理模块向open-iscsi的接收进程发送云硬盘强制回收命令。

由于本实施例中，800部分接收并解析的管理命令中，云硬盘标识对应的操作方式为强制回收，因此在803部分，管理模块向open-iscsi的接收进程发送了云硬盘强制回收命令。

当然，也可由宿主机管理模块自主决定是发送云硬盘强制回收命令还是发送云硬盘非强制回收命令，本发明不作具体的限定。

云硬盘强制回收命令中的操作方式用于表征强制性回收云硬盘。其他细节请参见本文前述400部分的介绍，在此不作赘述。

在804部分：接收进程接收到云硬盘强制回收命令后，会通知守护进程操作方式(强制回收)及云硬盘的标识。

在805部分：守护进程调用强制回收云硬盘资源的代码来清除与上述云硬盘的标识相关联的用户层内存资源。

上述用户层内存资源用于存储与上述云硬盘的标识相关联的描述信息。

在806部分：守护进程将云硬盘的标识传递至内核层，以用于内核层清除与上述云硬盘的标识相关联的内核层内存资源。

内核层内存资源用于存储上述云硬盘的盘符、块设备号以及会话信息。

需要说明的是，盘符、块设备号等是内核层分配给云硬盘的，所以由内核层负责回收。

在807部分：守护进程判断强制云硬盘回收是否成功，若是，向宿主机的管理模块返回表征回收成功的消息，否则，返回表征回收失败的消息。

如何判断是否回收成功可参见前述305部分的介绍，在此不作赘述。

宿主机的管理模块再通过一层层的信息传递，最终将表征回收成功的消息或表征回收失败的消息传递给回收系统。

若强制回收不成功，后续可进行人工干预，对强制回收云硬盘资源的代码进行调整和测试。

本发明实施例可作为现有云硬盘回收方案的一个补充，可保证在任何场景下，不需要重启宿主机，只需调用一个封装好的接口(open-iscsi的接收进程)即可强制回收云硬盘资源，保证宿主机系统运行环境干净，间接提高了宿主机运营服务能力。

图9示出了上述回收装置的一种可能的结构示意图，包括：接收单元901和强制回收单元902，其中：

接收单元901用于：接收并解析云硬盘回收命令，获取需回收的云硬盘的标识。

其中，所述云硬盘回收命令中包含操作方式和操作对象，所述操作方式用于表征回收云硬盘，所述操作对象包括需回收的云硬盘的标识；

强制回收单元902用于判断是否满足强制回收条件，并在判定满足所述强制回收条件时，对宿主机侧与所述云硬盘的标识相关联的云硬盘资源进行强制回收。

细节请参见前述方法部分的介绍，在此不作赘述。

其中，接收单元901可用于执行图3所示实施例的300部分，图4所示实施例的400部分，图5所示实施例的500部分，图6所示实施例的600部分，图7所示实施例的700部分和704部分，以及，图8所示实施例的800、801、803部分。

强制回收单元902可用于执行图3所示实施例的301-307部分，图4所示实施例的401-402部分，图5所示实施例的501-502部分，图6所示实施例的601-603部分，图7所示实施例的701-703部分和705-706部分，以及，图8所示实施例的802、805-807部分。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、WD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。