CN117827538A - Cloud desktop city-crossing disaster recovery method combined with snapshot technology - Google Patents
Cloud desktop city-crossing disaster recovery method combined with snapshot technology Download PDFInfo
- Publication number
- CN117827538A CN117827538A CN202311708930.8A CN202311708930A CN117827538A CN 117827538 A CN117827538 A CN 117827538A CN 202311708930 A CN202311708930 A CN 202311708930A CN 117827538 A CN117827538 A CN 117827538A
- Authority
- CN
- China
- Prior art keywords
- data
- disaster recovery
- cloud desktop
- buffer
- write
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 56
- 238000011084 recovery Methods 0.000 title claims abstract description 56
- 238000005516 engineering process Methods 0.000 title claims abstract description 21
- 230000008569 process Effects 0.000 claims abstract description 20
- 238000006243 chemical reaction Methods 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 3
- 230000000903 blocking effect Effects 0.000 abstract description 6
- 230000005540 biological transmission Effects 0.000 description 9
- 238000012545 processing Methods 0.000 description 6
- 230000001360 synchronised effect Effects 0.000 description 5
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000006854 communication Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 238000005096 rolling process Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Abstract
The invention belongs to the technical field of data disaster recovery, and particularly relates to a cloud desktop city-crossing disaster recovery method combined with a snapshot technology, which comprises the following steps of: the cloud desktop disaster recovery program sends a snapshot creation instruction; the drive module freezes all I/O write requests; generating a shadow copy by the disaster recovery program; the driving module intercepts all I/O write requests and exchanges the requests to a buffer area; and the synchronization module acquires the shadow copy and the buffer data and sends the shadow copy and the buffer data to a disaster recovery resource pool. The invention can acquire all read-write I/O requests in the process of creating the shadow snapshot and transmitting data, and perform high-efficiency data exchange on the I/O requests, can solve the problem of drive write-in I/O blocking, ensure consistency and continuity of snapshot data, and can solve the problem of full retransmission and ensure timeliness of disaster recovery data by storing 1 CRC check code for each data block to construct a full bitmap of disk blocks.
Description
Technical Field
The invention belongs to the technical field of data disaster recovery, and particularly relates to a cloud desktop city-crossing disaster recovery method combined with a snapshot technology.
Background
With the continuous development and depth of cloud desktop technology, the cloud desktop provides flexible and convenient computing services for users, and high availability gradually becomes a requirement of great attention of users. At present, openStack and Ceph between cloud desktop resource pools are mutually isolated, when sudden events such as natural disasters, hardware faults, software faults and the like are faced, if a resource pool where a virtual machine of a user is located fails, user data loss and service interruption are caused, so that a cloud desktop cross-resource pool virtual machine high availability technology needs to be realized, data of the virtual machine can be subjected to real-time or incremental disaster tolerance to another resource pool, and once the resource pool where the virtual machine is located fails, the user can quickly switch to the other resource pool for use. In the prior art, a cloud desktop cross-city disaster recovery scheme often depends on snapshot capability of underlying storage, RPO time is long, storage cost is high, targeted disaster recovery of a logical partition cannot be achieved, a real-time copying scheme is adopted, the requirement of application consistency is difficult to meet, network jitter, interruption and the like are easy to occur in a complex cross-city network environment, and once transmission fails, full retransmission is often required.
Disclosure of Invention
The invention aims to provide a cloud desktop city-crossing disaster recovery method combining snapshot technology, which can acquire all read-write I/O requests in the process of creating a shadow snapshot and transmitting data, and perform high-efficiency data exchange on the I/O requests without occupying extra snapshot storage space, synchronously transmit shadow copies and IRPs through a synchronization module, improve consistency and continuity of snapshot data, and simultaneously store 1 CRC check code through each data block to construct a full bitmap of disk blocks, thereby not only solving the full retransmission problem and the drive writing IO blocking problem, but also ensuring timeliness of disaster recovery data.
The technical scheme adopted by the invention is as follows:
a cloud desktop city-crossing disaster recovery method combining snapshot technology comprises the following steps:
the cloud desktop disaster recovery program sends a snapshot creation instruction;
the driving module freezes all I/O writing requests and refreshes the data of the buffer area;
generating a shadow copy by the disaster recovery program;
the driving module intercepts all I/O write requests and exchanges the requests to a buffer area;
the synchronization module acquires the shadow copy and the buffer data and sends the shadow copy and the buffer data to a disaster recovery resource pool;
when disaster recovery is switched, a client creates a backup cloud desktop, and establishes a read-write target of the backup cloud desktop as disaster recovery resource pool block equipment;
the buffer area comprises a buffer queue, a temporary buffer area and a data buffer area.
In a preferred embodiment, the buffer stores data in the form of data packets.
In a preferred embodiment, each data block in the buffer is stored with a CRC check code.
In a preferred embodiment, each data block in the buffer also stores a write status bit.
In a preferred embodiment, the packets in the buffer queue remain ordered and grow strictly monotonically.
In a preferred embodiment, the step before the driving module freezes all I/O write requests and flushes the buffer data further includes: the drive module redirects the write data to the temporary buffer.
In a preferred scheme, the drive module intercepts all I/O write requests and swaps to a buffer; comprising the following steps:
the cloud desktop disaster recovery program sends out an I/O request;
the driving module performs data conversion on the IRPs corresponding to all the I/O writing requests and stores the IRPs into the non-paging memory;
the cloud desktop disaster recovery program reads the non-paged memory data and exchanges the non-paged memory data to the data buffer area through the TCP connection.
In a preferred embodiment, the disaster recovery program generates a shadow copy according to a volume metadata structure and buffer data, and includes the following steps:
VSS enumerates all writers and all metadata for all writers;
writer creates metadata description, writes the data in the memory and the log into the database, and sends feedback information to VSS after writing is completed;
VSS writes the cache data of the file system in the memory to the source disk;
the Requester creates a shadow copy;
the VSS defreezes the file system, releases the Writer in an inactive state, and the VSS confirms whether the read/write I/O is successful in the process of creating the shadow copy;
if the response to the successful reading and writing is successful, the synchronization module sends the shadow copy and the buffer data to a disaster recovery resource pool and generates a corresponding snapshot;
and if the read-write failure is responded, deleting the shadow copy by the request.
The client is suitable for the cloud desktop city-crossing disaster recovery method combining the snapshot technology, and comprises a local calling module, wherein the local calling module can call cloud desktop image files in disaster recovery resource pool block equipment to provide local cloud desktop services for users.
A computer readable storage medium storing computer instructions that, when executed, perform a cloud desktop cross-city disaster recovery method incorporating snapshot techniques as described in any one of the above.
The invention has the technical effects that:
when the shadow copy is created, the I/O requests are acquired and frozen, data exchange is carried out on all the I/O requests, the I/O requests are converted into corresponding IRPs and stored in the temporary buffer area, the shadow copy and the IRPs are synchronously transmitted through the synchronization module without occupying extra snapshot storage space, and the consistency and the continuity of snapshot data are improved;
the disaster recovery range can be customized without computing resources and a shadow-rolling desktop, the disaster recovery desktop only needs to be created in the disaster recovery switching process, besides the local cache, simultaneously, a full bit map of the disk blocks is built by storing 1 CRC check code in each data block, and whether transmission is successful or not is judged by writing in status bits, so that the problems of full retransmission and driving writing IO blocking can be solved, cost expenditure can be saved, the timeliness of data transmission is improved, and the abnormal recovery and reconnection capability is realized.
Drawings
FIG. 1 is a schematic flow diagram of the overall invention;
fig. 2 is a schematic diagram of a buffering scheme of the present invention.
Detailed Description
In order that the above-recited objects, features and advantages of the present invention will become more readily apparent, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, but the present invention may be practiced in other ways other than those described herein, and persons skilled in the art will readily appreciate that the present invention is not limited to the specific embodiments disclosed below.
Further, reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic can be included in at least one implementation of the invention. The appearances of the phrase "in one preferred embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments.
Referring to fig. 1, a first embodiment of the present invention provides a cloud desktop city-crossing disaster recovery method combined with snapshot technology, which includes the following steps:
stp1: the cloud desktop disaster recovery program sends a snapshot creation instruction;
stp2: the driving module freezes all I/O writing requests and refreshes the data of the buffer area;
stp3: generating a shadow copy by the disaster recovery program;
stp4: the driving module intercepts all I/O write requests and exchanges the requests to a buffer area;
stp5: the synchronization module acquires the shadow copy and the buffer data and sends the shadow copy and the buffer data to a disaster recovery resource pool;
stp6: the disaster recovery resource pool generates a desktop snapshot according to the shadow copy and the temporary cache data;
stp7: when disaster recovery is switched, the client creates a backup cloud desktop, and establishes a read-write target of the backup cloud desktop as disaster recovery resource pool block equipment.
In a specific embodiment, the cloud desktop disaster recovery program sends a snapshot creation instruction, the request requests VSS to enumerate Writers and metadata thereof, prepares for the shadow copy, VSS initiates a request, temporarily freezes I/O write requests of each component to create a shadow copy, during this period, VSS writes the buff of the file system in the memory to the hard disk to ensure consistency of files in the hard disk, VSS notifies the request to create the shadow copy, after the shadow copy is created, VSS thaws the file system, releases Writers in an inactive state, waits for completion of all read-write IO operations in the queue, confirms whether read-write IO is successful or not in the process of creating the shadow copy by VSS, if so, starts to copy data of the shadow copy, generates a corresponding snapshot, if so, VSS notifies the request to delete the shadow copy, and the solution is fast in speed for data disaster recovery, and has the characteristics of multiple supporting scenes, strong supporting performance, is not compatible with the common user, and can not only support a common read-write, but also has a high capability of storing the cloud platform.
In a preferred embodiment, referring to fig. 2, the buffer area includes a buffer queue, a temporary buffer area and a data buffer area, and the buffer area stores data in the form of data packets, wherein the buffer queue is used for data synchronization between the data synchronization service and the target disk; the temporary buffer is used for temporarily storing the incremental snapshot metadata when the full amount is synchronized, because the incremental data must overwrite the full amount of data to maintain consistency of the data; the data buffer area is used for receiving the data pushing of the source disk in a full quantity, avoiding blocking the connection of the source disk, and supporting the signal of the pushing target to carry out flow control during pushing.
In this embodiment, the data is transmitted in the form of data packets, and the buffer area may be used to temporarily store the data packets and wait for the application program to process, so as to avoid the problems of data loss or data overflow caused by too fast processing speed of the application program, and the buffer queue is set, so that the temporary storage, sorting or scheduling of the data can be ensured to be effectively transferred to the target disk; when full synchronization is performed, incremental metadata such as an I/O request may be generated, in order to avoid the incremental metadata from being written into a target disk and setting a temporary buffer area, the metadata such as the I/O request can be temporarily stored, so that a data synchronization process is more flexibly processed, and important metadata is ensured not to be lost in the data synchronization process; when full data synchronization is performed, data is pushed from a source disk to a target disk, a data buffer area serves as a medium for receiving the pushed data, and a signal supporting the push target is needed to be used for flow control, so that the data flow is effectively managed, the target system is prevented from being incapable of normally processing due to data overload, the data transmission can be effectively managed and processed at a target end, the disaster tolerance range can be defined by the scheme, the disaster tolerance of a logical partition of an operating system can be supported, the disaster tolerance of specified files and directories can be also supported, the use cost is low, calculation resources are not needed, a rolling table top is not needed, the disaster tolerance table top is only created in the disaster tolerance switching process, and besides the local buffer storage, the efficiency of data synchronization, the data integrity and the data consistency can be effectively improved, the ordered and controllable transmission of the data can be realized, and meanwhile, the potential synchronization problem is avoided.
Furthermore, through the setting of the cache scheme, the disaster recovery increment problem of the cloud desktop can be solved, the stability and the abnormal recovery capacity of the backup process are improved, and meanwhile, the cache scheme has the following characteristics: 1. support breakpoint continuous transmission; 2. the data quantity required to be transmitted for connection recovery can be greatly reduced; 3. the data synchronized to the target disk is required to be available snapshot at any time point, namely, the data written to the target disk is required to be written according to the sequence of the increment data as far as possible; 4. the source disk data is extracted from the operating system, the write IO buffer area can be very small, protocol interaction is required to be designed, and synchronous blocking is avoided.
In a preferred embodiment, each data block in the buffer stores a CRC check code and a write status bit.
It should be noted that the CRC check code is a method for detecting errors in data transmission or storage. In this context, each data block is accompanied by a CRC check code, which is obtained by performing a special calculation on the content of the data block, which can be used by the recipient to verify the integrity of the data; the write status bit is a flag indicating the write status of a certain data block, the write status bit identifying whether the data block has been written or is being written.
In this embodiment, a data buffer area, a local temporary buffer area and a buffer queue are designed, a full bit map of a disk block is constructed by storing 1 CRC check code in each data block, and by writing status bits, whether transmission is successful or not is judged, and compared with the conventional public network scheme, the full retransmission problem and the drive writing I/O blocking problem can be solved, and compared with the private network scheme, cost overhead is saved, for example: if the write status bit of a data block is shown as "written," then it is indicated that the data in this data block has been completely written to the buffer; if the status bit is displayed as 'writing', the status bit indicates that the data block is being processed, and the writing process of the data is not completed yet.
In a specific embodiment, after a data packet is successfully sent, a CRC check code is calculated for the data packet and then recorded on an address corresponding to a bitmap, and a writing state is set to 1, otherwise, to 0, and once retransmission occurs, the new full data is compared with the bitmap snapshot, and the differential data is reissued to a target disk, so that unnecessary public network traffic can be reduced, retransmission amount is greatly reduced, and recovery speed is improved.
In a preferred embodiment, the packets in the buffer queue remain ordered and grow strictly monotonically.
In this embodiment, the buffer queue is a ring buffer.
The size of the buffer queue can be adjusted according to actual conditions, so that excessive memory is prevented from being occupied.
In this embodiment, the ring buffer is a common data structure, which can effectively solve the problem of coordination between two threads of a writer and a reader or between foreground and background systems when multithreading or foreground and background (interrupt) processing are respectively performed. The ring buffer identifies the storage location of the data and the location of the next read/write by maintaining an array of fixed size as storage space and setting two pointers. When a new data packet needs to be written, the new data packet is written into the buffer queue, and the alignment pointer is moved, so that the data packet stored in the buffer queue can maintain a specific sequence and incremental property in the transmission, processing or backup process, thereby being convenient for tracking the arrival sequence of the data packet, preventing the confusion of the data packet in the disaster recovery or backup process, and enhancing the reliability and the recovery capability of the system.
In one embodiment, the array may be expanded when the buffer queue is full, or data writing may be avoided by flow control logic.
In a preferred embodiment, the step before the drive module freezes all I/O write requests and file data and flushes the buffer data further comprises: the drive module redirects the write data to the temporary buffer.
In this embodiment, in the data disaster recovery, the driver module redirects write data to the temporary buffer area, which can solve the data processing problem when the host sends an I/O request to the disk and writes data to a certain LBA, specifically, when the host sends a write IO request to the disk array and writes changed data into the LUN from the buffer, the host data synchronization engine senses the change and sends the changed data block from the buffer to the spare buffer through the SAN switch, in this process, the driver module redirects the request to be written with data to the temporary buffer area, and only one write operation is needed to update the source data, thereby solving the performance problem of writing twice based on the copy-on-write technology. For example: when the data needs to be recovered due to faults, the data in the temporary buffer area can be recovered quickly, so that the consistency and the integrity of the data are ensured, and meanwhile, the I/O performance and the fault tolerance of the system are improved.
In a preferred embodiment, the driver module intercepts all I/O write requests and swaps them to the buffer; comprising the following steps:
the cloud desktop disaster recovery program sends out an I/O request;
the driving module performs data conversion on the IRPs corresponding to all the I/O writing requests and stores the IRPs into the non-paging memory;
the cloud desktop disaster recovery program reads the non-paged memory data and exchanges the non-paged memory data to the data buffer area through the TCP connection.
Further, the type of the IRP, i.e. the input/output request packet, mainly corresponds to the access type of the upper layer to the bottom layer device. For example, when an application program performs operations such as file-related input/output functions CreateFile, readFile, writeFile and CloseHandle, the operating system converts these operations into IRPs of the types irp_mj_create, irp_mj_read, irp_mj_write, irp_mj_close, and the like, and transfers these IRPs to the processing functions of the driver module. In addition, common I/O request types also include "Create" (for opening or creating a file or device), "Close" (for closing a file or device), "Read" (for reading data from a file or device), "Write" (for writing data to a file or device), and "I/O control" (for performing a particular I/O control operation), among others.
In this embodiment, for example, in the communication process of R3 and R0, the command and data of the application layer are encapsulated in the IRP structure by the system I/O manager, the IRP write request content including, but not limited to, the offset length, the size, and the Buffer content is fetched from the output Buffer by the application process, and when the Buffer length is required to be exceeded due to the limitation of the non-paged memory capacity, the IRP directly passes through the completion routine and returns to the original application process to require the application process to rewrite after the Buffer length is exceeded.
It should be noted that, in the operating system, R3 and R0 are two different authority levels, and the system kernel state refers to R0, which is the highest authority level, and mainly runs the system code; the user mode is R3, the authority level is lower, the user code is mainly operated, and the communication between R3 and R0 refers to the data exchange process between the two authority levels.
In a preferred embodiment, the disaster recovery program generates a shadow copy according to a volume metadata structure and buffer data, including the steps of:
VSS enumerates all writers and all metadata for all writers;
writer creates metadata description, writes the data in the memory and the log into the database, and sends feedback information to VSS after writing is completed;
VSS writes the cache data of the file system in the memory to the source disk;
the Requester creates a shadow copy;
the VSS defreezes the file system, releases the Writer in an inactive state, and the VSS confirms whether the read/write I/O is successful in the process of creating the shadow copy;
if the response to the successful reading and writing is successful, the synchronization module sends the shadow copy and the buffer data to a disaster recovery resource pool and generates a corresponding snapshot;
and if the read-write failure is responded, deleting the shadow copy by the request.
Furthermore, in this embodiment, the format of metadata description is an XML format, and XML is an open and customizable format, which supports multiple applications and languages, and has the advantages of lightweight, legibility, and the like, so that the basic features and attributes of metadata can be better described.
Note that in this embodiment, VSS (Volume Shadow Copy Service) is a part of an operating system service for ensuring that components can communicate and cooperate correctly; the request is software that actually requests to create a shadow copy, in this embodiment referred to as a backup program; writer is a component that actually guarantees consistency of data sets to be backed up, and is typically provided by various software vendors, such as SQLServer, exchange Server, etc.; provider is a component that is actually used to create and manage shadow copies, and this component may be an operating system, hardware, or backup software.
In this embodiment, the Requester requests VSS to enumerate Writers and their metadata, prepares for the shadow copy, VSS notifies Writers to prepare, writers to create a metadata description in XML format, write the data in memory and log to the database, after completion, feed back to VSS, VSS obtains feedback and sends a request to temporarily freeze the I/O write request of each component, to create a shadow copy (the time to freeze the I/O write request cannot exceed 60 seconds), during this period VSS writes the buff of the file system in memory to the hard disk to ensure consistency of the file in the hard disk, VSS notifies Requester to create the shadow copy (the time does not exceed 10 seconds), after the shadow copy is created, VSS unfreezes the file system, and releases the Writers in an inactive state, waits for all read/write IO operations in the queue to complete, VSS confirms whether read/write I/O was successful during the shadow copy creation, if read/write I/O failed, VSS notifies Requester to delete the shadow copy to ensure consistency of the file system to ensure consistency of the file in the hard disk, and if the read/write copy is successful, and the copy is started.
The client is suitable for the cloud desktop city-crossing disaster recovery method combined with the snapshot technology, and comprises a local calling module, wherein the local calling module can call cloud desktop image files in disaster recovery resource pool block equipment to provide local cloud desktop services for users.
A computer readable storage medium storing computer instructions that, when executed, perform a cloud desktop cross-city disaster recovery method incorporating snapshot techniques as described in any one of the above.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by computer program instructions and associated hardware, which may be stored on a non-transitory computer readable storage medium, and that the detection program, when executed, may comprise the steps of the embodiments of the methods described above. Any reference to a storage element, memory, database, or other medium provided herein and used in embodiments may include non-volatile and/or volatile storage elements. The non-volatile memory elements may include read-only memory elements (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile storage elements may include Random Access Memory (RAM) elements or external cache memory elements. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), storage element bus direct RAM (RDRAM), direct storage element bus dynamic RAM (DRDRAM), and storage element bus dynamic RAM (RDRAM), among others.
The foregoing is merely a preferred embodiment of the present invention and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present invention, which are intended to be comprehended within the scope of the present invention. Structures, devices and methods of operation not specifically described and illustrated herein, unless otherwise indicated and limited, are implemented according to conventional means in the art.
Claims (10)
1. A cloud desktop city-crossing disaster recovery method combining snapshot technology is characterized in that: the method comprises the following steps:
the cloud desktop disaster recovery program sends a snapshot creation instruction;
the driving module freezes all I/O writing requests and refreshes the data of the buffer area;
generating a shadow copy by the disaster recovery program;
the driving module intercepts all I/O write requests and exchanges the requests to a buffer area;
the synchronization module acquires the shadow copy and the buffer data and sends the shadow copy and the buffer data to a disaster recovery resource pool;
when disaster recovery is switched, a client creates a backup cloud desktop, and establishes a read-write target of the backup cloud desktop as disaster recovery resource pool block equipment;
the buffer area comprises a buffer queue, a temporary buffer area and a data buffer area.
2. The cloud desktop city-crossing disaster recovery method combined with snapshot technology according to claim 1, wherein the method is characterized in that: the buffer stores data in the form of data packets.
3. The cloud desktop city-crossing disaster recovery method combining snapshot technology according to claim 2, wherein the method is characterized in that: each data block in the buffer area stores a CRC check code.
4. The cloud desktop city-crossing disaster recovery method combining snapshot technology according to claim 2, wherein the method is characterized in that: each data block in the buffer also stores a write status bit.
5. The cloud desktop city-crossing disaster recovery method combining snapshot technology according to claim 2, wherein the method is characterized in that: the packets in the buffer queue remain ordered and grow strictly monotonically.
6. The cloud desktop city-crossing disaster recovery method combined with snapshot technology according to claim 1, wherein the method is characterized in that: the step before the drive module freezes all the I/O write requests and flushes the buffer data further includes: the drive module redirects the write data to the temporary buffer.
7. The cloud desktop city-crossing disaster recovery method combined with snapshot technology according to claim 1, wherein the method is characterized in that: the driving module intercepts all I/O write requests and exchanges the requests to a buffer area; comprising the following steps:
the cloud desktop disaster recovery program sends out an I/O request;
the driving module performs data conversion on the IRPs corresponding to all the I/O writing requests and stores the IRPs into the non-paging memory;
the cloud desktop disaster recovery program reads the non-paged memory data and exchanges the non-paged memory data to the data buffer area through the TCP connection.
8. The cloud desktop city-crossing disaster recovery method combined with snapshot technology according to claim 1, wherein the method is characterized in that: the disaster recovery program generates a shadow copy according to the volume metadata structure and the buffer data, and comprises the following steps:
VSS enumerates all writers and all metadata for all writers;
writer creates metadata description, writes the data in the memory and the log into the database, and sends feedback information to VSS after writing is completed;
VSS writes the cache data of the file system in the memory to the source disk;
the Requester creates a shadow copy;
the VSS defreezes the file system, releases the Writer in an inactive state, and the VSS confirms whether the read/write I/O is successful in the process of creating the shadow copy;
if the response to the successful reading and writing is successful, the synchronization module sends the shadow copy and the buffer data to a disaster recovery resource pool and generates a corresponding snapshot;
and if the read-write failure is responded, deleting the shadow copy by the request.
9. A client adapted to a cloud desktop city-crossing disaster recovery method in combination with snapshot technology as set forth in any one of claims 1 to 8, wherein: the cloud desktop image file management system comprises a local call module, wherein the local call module can call a cloud desktop image file in disaster recovery resource pool block equipment to provide local cloud desktop service for a user.
10. A computer-readable storage medium, characterized by: the computer readable storage medium stores computer instructions that, when executed, perform a cloud desktop cross-city disaster recovery method incorporating snapshot techniques as set forth in any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311708930.8A CN117827538A (en) | 2023-12-13 | 2023-12-13 | Cloud desktop city-crossing disaster recovery method combined with snapshot technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311708930.8A CN117827538A (en) | 2023-12-13 | 2023-12-13 | Cloud desktop city-crossing disaster recovery method combined with snapshot technology |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117827538A true CN117827538A (en) | 2024-04-05 |
Family
ID=90505229
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311708930.8A Pending CN117827538A (en) | 2023-12-13 | 2023-12-13 | Cloud desktop city-crossing disaster recovery method combined with snapshot technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117827538A (en) |
-
2023
- 2023-12-13 CN CN202311708930.8A patent/CN117827538A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8417907B2 (en) | Synchronizing snapshot volumes across hosts | |
| JP4809040B2 (en) | Storage apparatus and snapshot restore method | |
| US9442664B2 (en) | Efficient flashcopy backup target volume allocation from a shared resource pool | |
| US8024535B2 (en) | Techniques for producing a consistent copy of source data at a target | |
| US7406487B1 (en) | Method and system for performing periodic replication using a log | |
| US7177994B2 (en) | Checkpoint and consistency markers | |
| US9817724B2 (en) | Efficient FlashCopy backup target volume allocation with reuse and a shared resource pool | |
| US7921269B2 (en) | Storage subsystem and storage system for updating snapshot management information | |
| US9747046B2 (en) | Collision avoidance using dynamic target volume allocation in a single repository | |
| US20110066804A1 (en) | Storage device and information management system | |
| US9535617B2 (en) | Marking a flashcopy backup for collapse without breaking a flashcopy chain | |
| US7979651B1 (en) | Method, system, and computer readable medium for asynchronously processing write operations for a data storage volume having a copy-on-write snapshot | |
| US9817719B2 (en) | Efficient Flashcopy backup and mount, clone, or restore collision avoidance using dynamic volume allocation with reuse and from a shared resource pool | |
| US9454315B2 (en) | Efficient flashcopy backup target volume allocation from a shared resource pool while ingesting a flashcopy backup in a repository | |
| US9817723B2 (en) | Efficient FlashCopy backup and mount, clone, or restore collision avoidance using dynamic volume allocation with reuse | |
| US9542106B2 (en) | Efficient repository ingest of a target volume without breaking a flashcopy chain | |
| US7191284B1 (en) | Method and system for performing periodic replication using a log and a change map | |
| US9600188B2 (en) | Collision avoidance using dynamic target volume allocation from a shared resource pool | |
| US9817718B2 (en) | Efficient flashcopy backup and mount, clone, or restore collision avoidance using dynamic volume allocation from a shared resource pool | |
| CN117827538A (en) | Cloud desktop city-crossing disaster recovery method combined with snapshot technology | |
| JP2005215940A (en) | Storage system, server apparatus, and preceding copy data preparation method | |
| US9710339B2 (en) | Collision avoidance using dynamic volume allocation with reuse | |
| US9690500B2 (en) | Efficient flashcopy backup target volume allocation | |
| US9672118B2 (en) | Collision avoidance using dynamic target volume allocation | |
| US9632710B2 (en) | Efficient use of Flashcopy resources and target volumes for dynamic target volume allocation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination |