CN107888689A - 基于共享存储的加锁资源配置方法 - Google Patents
基于共享存储的加锁资源配置方法 Download PDFInfo
- Publication number
- CN107888689A CN107888689A CN201711138834.9A CN201711138834A CN107888689A CN 107888689 A CN107888689 A CN 107888689A CN 201711138834 A CN201711138834 A CN 201711138834A CN 107888689 A CN107888689 A CN 107888689A
- Authority
- CN
- China
- Prior art keywords
- logical volume
- volume
- resource allocation
- allocation method
- shared storage
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
Abstract
本发明揭示了基于共享存储的加锁资源配置方法，该方法包括：逻辑卷锁服务进程调用Device Mapper的映射表管理工具禁止卷组与真实目标设备之间的后续的IO请求操作，等待已经下发到逻辑卷的IO请求操作完成后，将多路径数据分发链路发生故障所对应的逻辑卷在Device Mapper的映射表所映射的真实目标设备替换成伪目标设备。通过本发明中，可在watchdog心跳超时避免sanlock触发watchdog所导致的计算节点被强制全部重置停机的现象，从而避免所在计算节点所挂载的其他虚拟机，尤其是避免了挂载ceph云硬盘的虚拟机也被强制中止响应的现象，从而提高了云平台的高可用性及稳定性。
Description
技术领域
本发明涉及云存储虚拟化技术领域，尤其涉及云计算中的虚拟化存储系统中的一种基于共享存储的加锁资源配置方法。
背景技术
共享存储作为云计算中的虚拟化存储系统中的主流存储方式，主要用于为虚拟机(VM)和上层业务提供数据支撑，并通过依赖于文件系统(file system)对共享存储进行管理。但是由于文件系统自身性能的限制，导致文件系统所提供的共享存储的性能远不如块存储，因此目前主流开源云计算平台中通常采用块存储对共享存储进行存储管理。
在块存储中，通常选用LVM(Logical Volume Manager，逻辑卷管理器)，并通过LVM对Linux环境对磁盘或者分区提供管理机制，以将底层的物理存储进行封装，并在物理磁盘与分区之上建立逻辑层，并以LV(Logical Volume，逻辑卷)的方式支撑上层应用。LVM支撑对磁盘的动态管理，能够根据业务量大小，增加或者减少为用户分配的虚拟存储，以实现高可用性与动态调整。
存储虚拟化技术是把一个大的存储池分解若干较小的存储单元，并把这些较小的存储单元单独挂载给虚拟机，作为一个虚拟磁盘使用。现有的存储虚拟化方法是通过LVM把卷组(VG)划分成若干LV，然后在LV中创建qcow2格式的虚拟磁盘。基于需要在多个计算节点同时操作该LV，因此通常在计算节点1中通过sanlock加锁LV后挂载给虚拟机(VM)进行使用。
不管是lvmlockd成功释放加锁资源及其锁还是watchdog触发重置计算节点而使其停机，此资源都可以在其它计算节点加锁并挂载给虚拟机。完成加锁后，在计算节点挂载LV给虚拟机的过程就是在Device Mapper中创建与LV对应的映射表。映射表将目标设备(即，LV所在VG下的PV)通过映射表中所保存的地址转换关系映射成虚拟块设备，虚拟机挂载这个虚拟块设备成为云硬盘。
在现有技术中，lvmlockd通过强制移除LV在Device Mapper中的映射表来释放对加锁资源(LV)的使用，即通过lvchange–an lv或者dmsetup remove lv映射表来释放对加锁资源(即加锁的LV)的使用，并在成功释放对LV的使用后，才可以安全地释放锁。
但是，当LV正在被使用时，即LV对应的云硬盘所挂载到虚拟机处于开机状态时，此时LV仍然处于正在被使用的状态，此时就无法移除映射表，最终导致释放资源(即LV)失败，watchdog心跳超时，计算节点被重置停机，而运行在这个计算节点的其它虚拟机(比如没有挂载LV，而是挂载了ceph存储的虚拟机)也将被一并重置停机，从而严重地影响了用户发起的业务，从而极大影响了用户对虚拟存储的访问，从而严重影响了用户体验。
有鉴于此，有必要对现有技术中的共享存储的加锁资源配置方法予以改进，以解决上述问题。
发明内容
本发明的目的在于公开一种共享存储的加锁资源配置方法，用以实现强制释放正在使用的逻辑卷，避免当watchdog心跳超时计算节点被重置停机，防止该计算节点上所加载的其他虚拟机无法向用户响应的现象，提高云平台的可靠性与安全性。
为实现上述目的，本发明揭示了一种基于共享存储的加锁资源配置方法，包括以下步骤：
S1、通过lsblk命令查询卷组中正在被使用和/或可用的逻辑卷，
S2、当计算节点中的卷组与底层存储设备中的所有多路径数据分发链路发生故障时，通过禁用多路径队列挂起机制来确保所有虚拟机对逻辑卷IO请求执行完毕；
S3、逻辑卷锁服务进程调用Device Mapper的映射表管理工具禁止卷组与真实目标设备之间的后续的IO请求操作，等待已经下发到逻辑卷的IO请求操作完成后，将多路径数据分发链路发生故障所对应的逻辑卷在Device Mapper的映射表所映射的真实目标设备替换成伪目标设备，而不直接移除多路径数据分发链路发生故障所对应的逻辑卷所对应的Device Mapper的映射表；
S4、逻辑卷锁服务进程调用sanlock释放所有逻辑卷的锁，以阻止计算节点强制停机，以释放所在计算节点上的虚拟机对于步骤S1中所述逻辑卷的使用。
作为本发明的进一步改进，所述步骤S1中的卷组与逻辑卷部署于同一计算节点中。
作为本发明的进一步改进，所述步骤S4中的“释放卷组所形成的所有逻辑卷的锁”具体为：通过调用drop vg命令，以释放卷组所形成的所有逻辑卷的锁。
作为本发明的进一步改进，所述步骤S1之后还包括：对正在被使用的逻辑卷遍历查询卷组所在的块设备的路径的步骤，所述块设备形成于真实目标设备中。
作为本发明的进一步改进，所述步骤S1中的逻辑卷形成加锁资源。
作为本发明的进一步改进，执行步骤S1之前还包括：
通过lsblk命令查询正在被使用的逻辑卷所依赖的底层存储设备与卷组之间是否形成多路径数据分发链路；
若是，则执行步骤S1；
若否，则跳转执行步骤S3；其中，
所述底层存储设备形成真实目标设备。
作为本发明的进一步改进，所述底层存储设备包括SAN存储与CEPH存储，当真实目标设备替换成伪目标设备后，仅隔离卷组与SAN存储之间的数据分发物理链路，且不隔离卷组与CEPH存储之间的数据分发物理链路。
作为本发明的进一步改进，所述逻辑卷为Delta Lease服务逻辑卷或者PaxosLease服务逻辑卷。
作为本发明的进一步改进，所述步骤S4中的“强制停机”具体为：linux内核的watchdog执行重置linux系统内核的操作或者通过IPMI对计算节点作强制断电的操作。
作为本发明的进一步改进，所述步骤S3中的“映射表管理工具”具体为：dmsetupwipe_table命令。
与现有技术相比，本发明的有益效果是：
当watchdog心跳超时，可在通过本发明避免sanlock触发watchdog所导致的计算节点被强制全部重置停机的现象，从而避免所在计算节点所挂载的其他虚拟机，尤其是可以有效地避免挂载ceph云硬盘的虚拟机也被强制中止响应的现象，从而提高了云平台的高可用性及稳定性。
附图说明
图1为使用本发明基于共享存储的加锁资源配置方法的一个云平台的拓扑图；
图2为在本发明中将多路径数据分发链路发生故障所对应的逻辑卷在DeviceMapper的映射表所映射的真实目标设备替换成伪目标设备的示意图。
具体实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
在详细阐述本发明的具体实现过程之前，对说明书中所涉及的专有技术名称进行限定与解释。
1、sanlock：基于共享存储的锁服务。
2、LVM：Logical Volume Manager，逻辑卷管理器。
3、Watchdog：Linux系统的看门狗程序。
4、lvmlockd：LVM锁服务组件，通过lvmlockd来调用sanlock服务。
5、VG：Volume Group卷组。
6、PV：Physical Volume，物理卷，VG由若干PV组成。
7、LV：Logical Volume，逻辑卷，由VG划分而成。
8、CEPH存储：基于linux系统的分布式存储系统，其与主机通过IP网络相通讯。
9、SAN存储：采用网状存储拓扑架构所形成的共享存储系统，其通过光纤网络与主机相通讯。
本实施方式所示出的基于共享存储的加锁资源配置方法是一种用于解决当云平台100中的一个或者多个计算节点中用位于后台并为云计算用户(即在本地或者远程对后端存储设备访问发起请求操作的终端用户)提供存储业务的底层存储设备与正在使用的、可用的或者部分可用而部分尚未分配给用户的虚拟机之间通过光纤网络(FC)所形成的SAN存储30之间的多路径数据分发链路发生故障时的解决方案。
Sanlock是一种基于软件实现的轻量级分布式锁管理器，其在oVirt、libvirt等开源虚拟化项目都有应用。集群中的每个计算节点都各自运行sanlock服务。
参图1所示，为简化说明，在本实施方式中计算节点、逻辑卷、卷组等技术特征均在图1中作范例性示出，本技术领域的技术人员可合理预测到某个计算节点中的虚拟机、卷组、逻辑卷的数量并不局限于图1所示，并可根据用户(GUEST)发起的访问请求或者对虚拟资源划分的需求而灵活设定。具体的，在本实施方式中，云平台100包括计算节点10与计算节点20。计算节点10包括虚拟机11和虚拟机12。计算节点20包括虚拟机21和虚拟机22。虚拟机11形成LV1及LV2。虚拟机12形成ceph云硬盘121。LV1～LV4可单独形成一个云硬盘。LV1～LV4可由VG1划分形成，并通过多路径数据分发链路(即图1中通过光纤网络101～光纤网络104所形成的数据链路)。同时，虚拟机21形成LV3及LV4，虚拟机22中形成ceph云硬盘221。计算节点10的linux内核中包括Device Mapper的映射表15，计算节点20的linux内核中包括Device Mapper的映射表25。虚拟机11、虚拟机12挂载虚拟块设备成为云硬盘，即由LV1～LV4所形成的云硬盘、虚拟机12中通过IP网络311所形成的ceph云硬盘，以及在虚拟机22中通过IP网络所形成的ceph云硬盘221。为云平台100提供底层存储设备服务的介质包括通过光纤网络101～过光纤网络104，即通过FC(光纤网络)或者iSCSI协议映射LUN设备301到所有计算节点(即，计算节点10和计算节点20)，计算节点10通过IP网络311访问CEPH存储40，计算节点20通过IP网络302访问CEPH存储40。
参图2所示，举例而言，当计算节点10挂载LV1到虚拟机11的流程如下：
调用lvchange–ay/dev/vg1/lv1命令，lvchange通过逻辑卷锁服务进程(lvmlockd)请求sanlock对LV1加锁，完成加锁操作后lvchange调用Device Mapper的映射表，以为lv1在Device Mapper中创建与块设备(即LUN设备301)之间的映射关系。至此，可将逻辑卷LV1挂载至虚拟机11，逻辑卷LV1在计算节点10中可作为块设备(Block Device)被直接访问。
需要说明的是，在本说明书中，术语“lv1”与术语“LV1”、术语“lv2”与术语“LV2”具等同技术含义。
当sanlock无法访问LUN设备301时，sanlock更新锁租约，并通知逻辑卷锁服务进程(lvmlockd)释放使用中的LV1锁，逻辑卷锁服务进程(lvmlockd)阻断虚拟机11对逻辑卷LV1的使用，并释放逻辑卷LV1在sanlock中的锁服务。逻辑卷LV1所预先加载的锁服务被释放后，sanlock恢复watchdog心跳，计算节点10及其计算节点10所创建的虚拟机12保持正常运行，并与作为后端存储设备中的CEPH存储40维持数据交换状态。云平台100通过上层HA软件(高可用性软件)，以在计算节点20中重新对逻辑卷LV1进行加锁，并且重建虚拟机11，以恢复对虚拟机11上用户业务对于LV1的IO请求。
具体的，在本实施方式中，该基于共享存储的加锁资源配置方法，该方法包括以下步骤。
首先，执行步骤S1：通过lsblk命令查询卷组中正在使用的、可用的或者部分可用而部分尚未分配给用户的逻辑卷。lsblk命令用于列出所有可用块设备(即图1中的LUN设备301)的信息以及所有可用块设备之间的依赖关系。
步骤S1中的卷组VG1与逻辑卷(LV1～LV4)部署于同一计算节点中，并通过上述逻辑卷(LV1～LV4)形成加锁资源。在本说明书中，所谓加锁资源可被理解为被sanlock加载锁服务的逻辑卷所形成的虚拟资源。优选的，在实施方式中，在步骤S1执行完成之后并在执行步骤S2之前还包括：对正在使用的逻辑卷遍历查询卷组VG1所在的块设备(即图1中的LUN设备301)的路径的步骤，所述块设备位于真实目标设备16中。亦即，此时块设备位于云平台100后端提供真实数据存储功能的SAN存储30中。
优选的，在本实施方式中，在执行步骤S1之前还包括：
通过lsblk命令查询正在被使用的逻辑卷所依赖的底层存储设备与卷组之间是否形成多路径数据分发链路；若是，则执行步骤S1；若否，则跳转执行步骤S3；其中，所述底层存储设备形成真实目标设备16。
然后，执行步骤S2：当计算节点中的卷组与底层存储设备中的所有多路径数据分发链路发生故障时，通过禁用多路径队列挂起机制来确保所有虚拟机对逻辑卷IO请求执行完毕。
如果采用现有技术中调用正常的释放锁的逻辑(通过现有命令lvchange–an lv)来释放加锁资源的话，则当逻辑卷LV正在被使用时(例如计算节点10中的虚拟机12与CEPH存储40正在进行数据交换时)，就无法释放该加锁资源，并最终导致sanlock触发watchdog而使得云平台100发生系统崩溃的严重风险。
然后，执行步骤S3：逻辑卷锁服务进程调用Device Mapper的映射表管理工具禁止卷组VG1与真实目标设备16之间的后续的IO请求操作，等待已经下发到逻辑卷的IO请求操作完成后，将多路径数据分发链路发生故障所对应的逻辑卷在Device Mapper的映射表所映射的真实目标设备16替换成伪目标设备17，而不直接移除多路径数据分发链路发生故障所对应的逻辑卷所对应的Device Mapper的映射表。其中，该步骤S3中的“映射表管理工具”具体为：dmsetup wipe_table命令。
结合图2所示，具体的，在该底层存储设备由图1中的SAN存储30与CEPH存储40组成。当真实目标设备16替换为伪目标设备17后，仅隔离卷组VG1与SAN存储30之间的数据分发物理链路，且不隔离卷组VG1与CEPH存储40之间的数据分发物理链路，从而避免了在上述操作过程中被挂载ceph云硬盘121的虚拟机12及被挂载ceph云硬盘221的虚拟机22也被强制中止响应，从而提高了云平台100的高可用性及稳定性。其中，所述伪目标设备17形成于linux内核中，且不在SAN存储30中占用物理的字节空间，同时也会在Device Mapper的映射表15或者Device Mapper的映射表25中形成逻辑卷与伪目标设备17之间的映射关系。同时，本实施方式中的所述逻辑卷为Delta Lease服务逻辑卷或者Paxos Lease服务逻辑卷。通过步骤S3，使得后续的IO请求直接向逻辑卷LV1返回错误响应，从而不会使用户对LUN设备301进行数据访问操作。
通常的，LVM通过lvmlockd锁服务来控制并发操作，以防止LVM元数据损坏，lvmlockd使用sanlock来提供锁机制。在本实施方式中，当所有逻辑卷LV的真实目标设备16被替换伪目标设备17时，调用lvmlockctl命令，及drop vg命令来释放锁资源，从而避免sanlock触发watchdog机制。
sanlock有两种心跳信息，一是通过向底层存储设备写入心跳信息来更新已加锁的租约，保持加锁状态；二是与watchdog保持心跳。sanlock在无法访问存储来更新已加锁资源(LV)的锁租约时，会停止向watchdog发送心跳，并要求lvmlockd释放加锁资源，如果lvmlockd无法释放加锁资源，就无法释放锁，那么watchdog最终会因心跳超时导致重置计算节点使其停机来达到强制释放加锁资源的目的。因此，在本发明中，可通过lvmlockd释放加锁资源并释放锁，从而使得sanlock实现恢复watchdog心跳的目的，从而实现了避免重置计算节点而使其停机的有益效果。
当SAN存储30发生故障或者计算节点中的虚拟机至SAN存储30之间的多路径数据分发链路(即multipath)发生故障时，sanlock无法更新自己的心跳，从而导致其触发通知lvmlockd来释放sanlock已经占有的锁资源的机制，以保证其它计算节点不会且永远无法获取锁而使得服务失效。
最后，当所有卷组VG1中的所有逻辑卷被替换为伪目标设备17后，执行步骤S4：逻辑卷锁服务进程(lvmlockd)调用sanlock释放所有逻辑卷的锁，以阻止计算节点11强制停机，以释放所在计算节点11上的虚拟机11及虚拟机12对于步骤S1中所述逻辑卷(LV1～LV4)的使用。其中，所述步骤S4中的“强制停机”具体为：linux内核的watchdog执行重置linux系统内核的操作或者通过IPMI对计算节点作强制断电的操作。所述步骤S4中的“释放卷组所形成的所有逻辑卷的锁”具体为：通过调用drop vg命令，以释放卷组所形成的所有逻辑卷的锁。因此，通过本发明可防止“错杀”计算节点10与计算节点20与CEPH存储40之间通过IP网络311、IP网络302所形成的数据分发路径，从而提高了该云平台100的高可用性与稳定性。
在本实施方式中，通过禁止多路径队列挂起机制(multipath disablequeuing)及映射表管理工具，保证了加锁资源被强制隔离访问，从而可以释放锁，避免触发watchdog机制。
上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。
Claims (10)
1.一种基于共享存储的加锁资源配置方法，其特征在于，包括以下步骤：
S1、通过lsblk命令查询卷组中正在被使用和/或可用的逻辑卷，
S2、当计算节点中的卷组与底层存储设备中的所有多路径数据分发链路发生故障时，通过禁用多路径队列挂起机制来确保所有虚拟机对逻辑卷IO请求执行完毕；
S3、逻辑卷锁服务进程调用Device Mapper的映射表管理工具禁止卷组与真实目标设备之间的后续的IO请求操作，等待已经下发到逻辑卷的IO请求操作完成后，将多路径数据分发链路发生故障所对应的逻辑卷在Device Mapper的映射表所映射的真实目标设备替换成伪目标设备，而不直接移除多路径数据分发链路发生故障所对应的逻辑卷所对应的Device Mapper的映射表；
S4、逻辑卷锁服务进程调用sanlock释放所有逻辑卷的锁，以阻止计算节点强制停机，以释放所在计算节点上的虚拟机对于步骤S1中所述逻辑卷的使用。
2.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述步骤S1中的卷组与逻辑卷部署于同一计算节点中。
3.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述步骤S4中的“释放卷组所形成的所有逻辑卷的锁”具体为：通过调用drop vg命令，以释放卷组所形成的所有逻辑卷的锁。
4.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述步骤S1之后还包括：对正在被使用的逻辑卷遍历查询卷组所在的块设备的路径的步骤，所述块设备形成于真实目标设备中。
5.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述步骤S1中的逻辑卷形成加锁资源。
6.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，执行步骤S1之前还包括：
通过lsblk命令查询正在被使用的逻辑卷所依赖的底层存储设备与卷组之间是否形成多路径数据分发链路；
若是，则执行步骤S1；
若否，则跳转执行步骤S3；其中，
所述底层存储设备形成真实目标设备。
7.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述底层存储设备包括SAN存储与CEPH存储，当真实目标设备替换成伪目标设备后，仅隔离卷组与SAN存储之间的数据分发物理链路，且不隔离卷组与CEPH存储之间的数据分发物理链路。
8.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述逻辑卷为Delta Lease服务逻辑卷或者Paxos Lease服务逻辑卷。
9.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述步骤S4中的“强制停机”具体为：linux内核的watchdog执行重置linux系统内核的操作或者通过IPMI对计算节点作强制断电的操作。
10.根据权利要求1所述的基于共享存储的加锁资源配置方法，其特征在于，所述步骤S3中的“映射表管理工具”具体为：dmsetup wipe_table命令。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711138834.9A CN107888689B (zh) | 2017-11-16 | 2017-11-16 | 基于共享存储的加锁资源配置方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711138834.9A CN107888689B (zh) | 2017-11-16 | 2017-11-16 | 基于共享存储的加锁资源配置方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107888689A true CN107888689A (zh) | 2018-04-06 |
| CN107888689B CN107888689B (zh) | 2019-04-30 |
Family
ID=61777515
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711138834.9A Active CN107888689B (zh) | 2017-11-16 | 2017-11-16 | 基于共享存储的加锁资源配置方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107888689B (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109032753A (zh) * | 2018-06-20 | 2018-12-18 | 上海市信息网络有限公司 | 一种异构虚拟机硬盘托管方法、系统、存储介质及Nova平台 |
| CN109375988A (zh) * | 2018-11-01 | 2019-02-22 | 郑州云海信息技术有限公司 | 一种分布式锁实现方法和装置 |
| CN109725856A (zh) * | 2018-12-29 | 2019-05-07 | 深圳市网心科技有限公司 | 一种共享节点管理方法、装置、电子设备及存储介质 |
| CN111355775A (zh) * | 2019-12-30 | 2020-06-30 | 深圳创新科技术有限公司 | CloudStack集群子服务器状态判断方法、装置、设备及存储介质 |
| CN113064546A (zh) * | 2020-01-02 | 2021-07-02 | 阿里巴巴集团控股有限公司 | 一种文件系统的管理方法、装置、文件系统及存储介质 |
| CN116382850A (zh) * | 2023-04-10 | 2023-07-04 | 北京志凌海纳科技有限公司 | 一种利用多存储心跳检测的虚拟机高可用管理装置及系统 |
| WO2024051468A1 (zh) * | 2022-09-09 | 2024-03-14 | 中电信数智科技有限公司 | 一种解决集群逻辑卷并发激活和反激活的新方法 |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005057350A (ja) * | 2003-08-06 | 2005-03-03 | Hitachi Ltd | ストレージネットワーク管理装置及び方法 |
| CN1664793A (zh) * | 2005-03-11 | 2005-09-07 | 清华大学 | 基于元数据服务器的存储虚拟化管理方法 |
| CN101506779A (zh) * | 2006-06-20 | 2009-08-12 | 雷特泽遥距管理有限责任公司 | 生成存储系统命令 |
| CN101510143A (zh) * | 2009-03-13 | 2009-08-19 | 杭州华三通信技术有限公司 | 动态分配存储空间的方法、系统和存储装置 |
| CN101751228A (zh) * | 2009-12-29 | 2010-06-23 | 成都市华为赛门铁克科技有限公司 | 磁盘阵列的实现方法和数据读写方法及装置 |
| CN101997918A (zh) * | 2010-11-11 | 2011-03-30 | 清华大学 | 异构san环境中的海量存储资源按需分配的实现方法 |
| CN102799533A (zh) * | 2012-07-10 | 2012-11-28 | 浙江宇视科技有限公司 | 一种磁盘损坏扇区屏蔽方法及装置 |
| CN104268061A (zh) * | 2014-09-12 | 2015-01-07 | 国云科技股份有限公司 | 一种适用于虚拟机的存储状态监控机制 |
| CN105808157A (zh) * | 2014-12-31 | 2016-07-27 | 中兴通讯股份有限公司 | 存储架构的创建方法、存储访问方法和存储系统 |
| CN105988723A (zh) * | 2015-02-12 | 2016-10-05 | 中兴通讯股份有限公司 | 一种快照处理方法及装置 |
-
2017
- 2017-11-16 CN CN201711138834.9A patent/CN107888689B/zh active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005057350A (ja) * | 2003-08-06 | 2005-03-03 | Hitachi Ltd | ストレージネットワーク管理装置及び方法 |
| CN1664793A (zh) * | 2005-03-11 | 2005-09-07 | 清华大学 | 基于元数据服务器的存储虚拟化管理方法 |
| CN101506779A (zh) * | 2006-06-20 | 2009-08-12 | 雷特泽遥距管理有限责任公司 | 生成存储系统命令 |
| CN101510143A (zh) * | 2009-03-13 | 2009-08-19 | 杭州华三通信技术有限公司 | 动态分配存储空间的方法、系统和存储装置 |
| CN101751228A (zh) * | 2009-12-29 | 2010-06-23 | 成都市华为赛门铁克科技有限公司 | 磁盘阵列的实现方法和数据读写方法及装置 |
| CN101997918A (zh) * | 2010-11-11 | 2011-03-30 | 清华大学 | 异构san环境中的海量存储资源按需分配的实现方法 |
| CN102799533A (zh) * | 2012-07-10 | 2012-11-28 | 浙江宇视科技有限公司 | 一种磁盘损坏扇区屏蔽方法及装置 |
| CN104268061A (zh) * | 2014-09-12 | 2015-01-07 | 国云科技股份有限公司 | 一种适用于虚拟机的存储状态监控机制 |
| CN105808157A (zh) * | 2014-12-31 | 2016-07-27 | 中兴通讯股份有限公司 | 存储架构的创建方法、存储访问方法和存储系统 |
| CN105988723A (zh) * | 2015-02-12 | 2016-10-05 | 中兴通讯股份有限公司 | 一种快照处理方法及装置 |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109032753A (zh) * | 2018-06-20 | 2018-12-18 | 上海市信息网络有限公司 | 一种异构虚拟机硬盘托管方法、系统、存储介质及Nova平台 |
| CN109032753B (zh) * | 2018-06-20 | 2022-02-22 | 上海市信息网络有限公司 | 一种异构虚拟机硬盘托管方法、系统、存储介质及Nova平台 |
| CN109375988A (zh) * | 2018-11-01 | 2019-02-22 | 郑州云海信息技术有限公司 | 一种分布式锁实现方法和装置 |
| CN109725856A (zh) * | 2018-12-29 | 2019-05-07 | 深圳市网心科技有限公司 | 一种共享节点管理方法、装置、电子设备及存储介质 |
| CN111355775A (zh) * | 2019-12-30 | 2020-06-30 | 深圳创新科技术有限公司 | CloudStack集群子服务器状态判断方法、装置、设备及存储介质 |
| CN111355775B (zh) * | 2019-12-30 | 2022-11-18 | 深圳创新科技术有限公司 | CloudStack集群子服务器状态判断方法、装置、设备及存储介质 |
| CN113064546A (zh) * | 2020-01-02 | 2021-07-02 | 阿里巴巴集团控股有限公司 | 一种文件系统的管理方法、装置、文件系统及存储介质 |
| CN113064546B (zh) * | 2020-01-02 | 2024-02-09 | 阿里巴巴集团控股有限公司 | 一种文件系统的管理方法、装置、文件系统及存储介质 |
| WO2024051468A1 (zh) * | 2022-09-09 | 2024-03-14 | 中电信数智科技有限公司 | 一种解决集群逻辑卷并发激活和反激活的新方法 |
| CN116382850A (zh) * | 2023-04-10 | 2023-07-04 | 北京志凌海纳科技有限公司 | 一种利用多存储心跳检测的虚拟机高可用管理装置及系统 |
| CN116382850B (zh) * | 2023-04-10 | 2023-11-07 | 北京志凌海纳科技有限公司 | 一种利用多存储心跳检测的虚拟机高可用管理装置及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107888689B (zh) | 2019-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107888689A (zh) | 基于共享存储的加锁资源配置方法 | |
| EP3287906B1 (en) | Method, system, and apparatus for cloud application redundancy | |
| CN106919346B (zh) | 一种基于clvm的共享存储虚拟化实现方法 | |
| CN103763383B (zh) | 一体化云存储系统及其存储方法 | |
| CN101414277B (zh) | 一种基于虚拟机的按需增量恢复容灾系统及方法 | |
| CN105187249B (zh) | 一种故障恢复方法及装置 | |
| CN103368768A (zh) | 混合云环境中具有启发式监视的自动缩放网络覆盖 | |
| CN103677967A (zh) | 一种数据库的远程数据服务系统及任务调度方法 | |
| CN106874136A (zh) | 一种存储系统的故障处理方法及装置 | |
| CN101094154B (zh) | 一种多主控模式的数据备份异地保护系统以及保护方法 | |
| CN106357787A (zh) | 一种存储容灾控制系统 | |
| CN104486445A (zh) | 一种基于云平台的分布式可扩展资源监控系统及方法 | |
| CN110377395A (zh) | 一种Kubernetes集群中的Pod迁移方法 | |
| CN104836819A (zh) | 动态负载均衡的方法、系统及监控调度设备 | |
| CN101118521A (zh) | 跨越多个逻辑分区分布虚拟输入/输出操作的系统和方法 | |
| CN105095094A (zh) | 内存管理方法和设备 | |
| CN103229535A (zh) | 电信网络中用于单元恢复的方法和系统 | |
| CN110912991A (zh) | 一种基于超融合双节点高可用的实现方法 | |
| EP3280094B1 (en) | Disaster recovery method, device, and system | |
| CN108600316A (zh) | 云存储服务的数据管理方法、系统及设备 | |
| CN102664757B (zh) | 一种存储设备的级联方法及装置 | |
| US8392534B2 (en) | Device for access to data aboard an aircraft | |
| CN109522145A (zh) | 一种虚拟机故障自动恢复系统及其方法 | |
| CN109508261A (zh) | 一种基于大数据的电网数据节点备份方法及备份系统 | |
| CN108464031B (zh) | 电信网络中的基于数据库的冗余 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |