CN1256672C - Remote data flexible replication system and method - Google Patents

Abstract

Methods, systems, and configured storage media are provided for flexible data mirroring. In particular, the invention provides local-remote role reversal (1506), implementation of hot standby server status through a ''media not ready'' signal (1508), several alternate buffer contents and buffering schemes, transactioning (1516), many-to-one mirroring through use of ''virtual'' remote mirroring units (1520), identification (1522) of frequently accessed data withbout application-specific knowledge but based instead on an application's logged and analyzed behavior, and use (1526) of the secondary server in a non-authoritative manner.

Description

Remote data flexible replication system and method

field of invention

The present invention relates to a remote replication of digital data by a server or other computer to provide better fault tolerance and/or recovery from accidents, especially its tools and techniques to increase the flexibility of remote data replication.

Technical Background of the Invention

US Patent No. 5,537,533 describes tools and techniques for remote copying of digital data from a host network server to a remote network server. The system according to this patent includes a master data transfer unit having a master server interface and a master link interface, and a remote data transfer unit having a remote link interface and a remote server interface. The main link interface includes a spoofed packet generator capable of generating "pre-acknowledgment" to the main network server. In other words, the system has "smart buffers" that send data after the replicated data has been stored in a non-volatile buffer within the main link interface, but before a response message arrives stating that the replicated data has been stored on the remote server. Give the master server a pre-confirmation, or "spoof" message.

MiraLink Corporation of Salt Lake City, Utah is the owner of US Patent No. 5,537,533. The company has marketed the Off-SiteServer product (Off-SiteServer is a trademark of MiraLink Corporation) one year before this application. The Off-SiteServer product includes the technology of remotely copying the Novell NetWare server disk (NetWare is a trademark of Novell Corporation) to another geographically remote server through a low-bandwidth communication link.

Utilizing the data duplication method, the remote data duplication carried out from the main network server to the remote replacement network server is a powerful data backup method. Remote replication creates copies of data from original data at a safe distance, and the operation is essentially synchronous with storing the original data. After a serious accident, if the data stored remotely is stored in a "warm machine" remote network server, the data can be used almost immediately, in other words, within a few minutes after a real or simulated disaster, the remote server can be updated. The main web server role of the server is activated and executed.

In the general installation procedure, using the Off-SiteServer product will involve a pair of Off-SiteServer boxes: one is a local box and the other is a remote box. The Off-SiteServer box is configured with dedicated hardware, firmware and/or other software as outlined in US Patent No. 5,537,533. Connect the local NetWare server to one of the boxes using a dedicated serial cable. The NetWare server itself uses a Vinca adapter card (VINCA is a trademark of Vinca Corporation). The adapter card is driven by "NetWare Loadable Module (NLM)". This program intercepts the request from the hard disk drive, and then transmits the data to the local Off-SiteServer box through the serial line.

The local Off-SiteServer box has 4Gigabytes such as non-volatile buffers like IDE hard drives. Enter the Off-SiteServer buffer after confirming the data in advance. For the operating system of the local server, a second "copy" write operation will be performed on the local side. In fact, the Off-SiteServer product has received the data by NLM and stored it in the local buffer. The local Off-SiteServer box will store the sector and track change data until the box can safely transmit the data to the remote Off-SiteServer box at a distance. The buffer of the local Off-SiteServer box is also "intelligent", so that it can store any data that can be processed regionally on the communication link. The data will be stored in the local Off-SiteServer machine box until the remote Off-SiteServer machine box has successfully written it into the remote second server, and returns a confirmation signal to the local Off-SiteServer machine box. After receiving the acknowledgment signal, the Off-SiteServer box at the local end releases the non-volatile buffer space originally occupied by the successfully transmitted sector/track/block data at the local end.

The Off-SiteServer product uses V.35 interface for data output at the local end. V.35 is a serial communication standard connected to "Channel Service Unit/Data Service Unit (CSU/DSU)" and then interfaced with the communication network. A second CSU/DSU is provided at the remote (second) location to relay the sector/track/block data to the V.35 input interface of the remote second Off-SiteServer box. The remote second Off-SiteServer box is connected to another dedicated serial line of the Vihca adapter card in the remote second server through a serial cable, and outputs the sector/track/block data. Then, the remote server data replication and system software write the sector/track/block data into the remote server disk drive, and reply the write operation confirmation message to the local Off-SiteServer box. The system can handle about 300Mega bytes of data change operations within one hour.

The Off-SiteServer is smart enough to sense if the bandwidth increases or decreases, and/or if the communication link is broken. During the link interruption period, the Off-SiteServer box can store the changed data in the local non-volatile intelligent buffer. And when the link is activated again, the Off-SiteServer box will start to transmit data automatically. For example, when the available bandwidth becomes more or less, the Off-SiteServer box can change its output bandwidth at any time. All of the above transfer operations also incorporate standard software-based error checking detection and correction, and/or hardware-based error correction code (ECC) error handling.

In case a disk or a server crash occurs in the local (main) NetWare server, the second (remote) server attached to the remote (second) Off-SiteServer box can have a local (main) A full duplicate disk copy of all material on the server. The remote backup copy can be stored on the local (primary) server. And when an accident occurs, the second remote server can also replace the local main server. This second restore and/or replacement operation can be performed in a very rapid manner with simple instructions.

In short, Off-SiteServer products and other data replication technologies can provide valuable fault tolerance and disaster recovery capabilities for important work data or files. However, the flexibility of these existing solutions is unnecessarily limited.

For example, the Off-SiteServer product requires a specific Vinca hardware and software version. In addition to Novell NetWare platform, this version requirement of Vinca products does not support other operating system/file system platforms. Also, the hardware components necessary for the Vinca package are not compatible with newer, faster servers and larger disk capacities.

The original Off-SiteServer product is also designed for connecting a local server to a remote server. Only a single local server can be replicated to a remote server at a given time. Multiple servers in different locations cannot replicate to a single remote at once. Similarly, if a company has multiple local servers using multiple operating systems and/or file systems, each server running a specific operating platform must be copied to its corresponding remote server.

In addition, the original Off-SiteServer product needs to install NLM on the local server, and it is designed to use private and dedicated communication links. Traditional replication also requires a remote server to maintain the replicated information remotely in a bootable format.

These limitations and others are noted in patent application Ser. No. 09/438,184. This application may provide additional tools and techniques for remote data replication to take advantage of the techniques described in the parent application, as well as other advances.

Invention purpose and overview

The present invention can provide a data replication tool and technology, which can be used together in the invention of the patent application or in other specific embodiments. The present summary focuses on tools and techniques not previously detailed. For example, the present invention can provide things like local-remote role swap, hot standby server state implementation with a "media not standby" signal, several alternative buffer contents and buffering laws, transactions, use of "virtual" remote Many-to-one replication processing of replication units, identification processing of frequently accessed data without application-specific knowledge but additionally based on registration and analysis behavior of application items, and tools and techniques for using second servers in an unauthorized manner. Other characteristics and advantages of the present invention will be better understood through the following description.

Simple schematic diagram

In order to illustrate how the present invention achieves its advantages and characteristics, the detailed description of the present invention will be described with reference to the attached schematic diagram. The schematic diagram only describes several features of the present invention, but the present invention is not limited thereto.

FIG. 1 is a schematic diagram illustrating an existing computer network replication, which technology can be adapted for the present invention.

Figure 2 is a schematic diagram illustrating a computer system according to the present invention, without a remote server, but including a remote replication unit with a relatively large buffer.

3 is a schematic diagram illustrating a computer system according to the present invention, including a remote server with a "hot-swappable" RAID unit, and a remote replication unit with a relatively small buffer.

Figure 4 is a schematic diagram illustrating a computer system according to the present invention, without a remote server, but including a remote replication unit with a relatively small buffer and hot-swappable RAID units.

Figure 5 is a schematic diagram illustrating a many-to-one replicating computer system consistent with the present invention, having no remote servers, but including multiple local servers executing a particular platform each with its own local replicating unit, and a single server with a relatively small buffer and multiple Remote replication unit for hot-swappable RAID units.

6 is a schematic diagram illustrating another many-to-one replicating computer system consistent with the present invention, having no remote servers but including multiple local servers each with its own local replicating unit executing a particular platform, and a single server with a relatively small buffer and Multiple remote replication units with individual external storage file directories.

7 is a schematic diagram illustrating another many-to-one replicating computer system consistent with the present invention, having no remote servers but including multiple local servers each with its own local replicating unit executing a particular platform, and a single relatively small buffer, A single individual external storage file directory with multiple partitions, and a remote replication unit with a hot-swappable RAID unit also with multiple partitions.

8 is a schematic diagram illustrating another many-to-one replicating computer system consistent with the present invention, having no remote server but including multiple local servers each with its own local replicating unit executing a different platform, and a single server with a relatively small buffer and multiple Remote replication unit for hot-swappable RAID units.

9 is a schematic diagram illustrating another many-to-one replicating computer system consistent with the present invention, having no remote server but including multiple local servers each with its own local replicating unit executing a different platform, and a single server with a relatively small buffer and multiple A remote replication unit for externally stored file directories.

Figure 10 is a schematic diagram illustrating another many-to-one replicating computer system consistent with the present invention, having no remote server but including multiple local servers each with its own local replicating unit executing a different platform, and a single, relatively small buffer, a An external storage file directory with multiple partitions, and a remote replication unit that is also a hot-swappable RAID unit with multiple partitions.

11 is a schematic diagram illustrating another one-to-many replication computer system in accordance with the present invention, wherein a local server is connected to multiple local replication units for replicating data to multiple remote locations.

12 is a schematic diagram illustrating another one-to-many replication computer system in accordance with the present invention, wherein a local server is connected to a multi-ported local replication unit to replicate data to multiple remote locations.

Figure 13 is a flowchart illustrating the method of the present invention.

FIG. 14 is a schematic diagram illustrating a dual-host configuration among remote replication units, remote servers, and RAID units, and switching operations in accordance with the present invention can be performed.

Figure 15 is a flow chart further illustrating the method of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention relates to computer systems and methods for elastic data replication. The present invention can provide a non-intrusive replication, replication with or without a dedicated private communication link, and replication with or without a dedicated server or another server at the destination to assist the remote replication unit. The present invention can also provide many-to-one data replication, including replication from local servers at two or more geographically distributed locations, running the same or different operating systems and/or file systems. Furthermore, the present invention can provide flexibility by allowing replicated data to be stored using various combinations of one or more external storage units and/or RAID units.

The invention also provides tools and techniques for elastic data replication. Includes replica unit role reversal; server hot standby mode operation; replicated data storage options; storage and re-import of SCSI commands related to changed data; transactions; virtual replica units; application state restoration; and data volume resynchronization. These topics are described with reference to Figure 15, and it should be understood that the appropriate information on a given topic does not necessarily appear only in Figure 15 and the text directly referred to therein.

The present invention can be implemented according to various methods and systems. Unless otherwise specified, the discussion and description of any specific embodiment is also applicable to other forms of specific embodiments. For example, descriptions of the systems of the present invention are also helpful in understanding the inventive methods for configuring these systems and/or methods to transmit data through these systems to obtain replicated data, and vice versa. In particular, although FIG. 15 shows a flowchart, this is not limited to the method, but is also useful in describing media and systems configured in accordance with the present invention.

Introduction to Computer and Network

FIG. 1 depicts a network 100 in which the local server 102 is replicated to a remote server 106 via conventional routing 104 . The conventional router 104 is not limited to communication links, but includes modems, data transmission units, and other conventional tools and techniques for transmitting and/or receiving data transmitted over the link. In particular, but not limited to, the legacy router 104 may include server interfaces, link interfaces, and DTUs as illustrated in FIG. 1 US Patent No. 5,537,533 and its discussion.

Additionally, the legacy router 104 may include Small Computer System Interface (SCSI) performance expanders, or standard Storage Access Network (SAN) connectors. These devices require an extremely high bandwidth link with the lowest possible latency. The distance is generally or limited to 10 to 20 miles because the distance will cause delay problems. For example, in a single-mode fiber configuration, a given SCSI extender can allow a distance of about 15 kilometers between the data source and destination due to latency issues. With a multimode fiber configuration, about two-thirds the usable distance is due to latency issues. For such links, no delays or interruptions of less than a fraction of a second per second, or processing delays of at most a few seconds, are allowed or are not allowed. The same problem happens with mainframe channel extenders.

While the schematic network 100 is set up for replication in accordance with conventional tools and techniques, there may be many networks suitable for adaptation and use in accordance with the present invention. This adjustment operation includes various steps, depending on the particular embodiment of the invention. For example, this adjustment operation may include disconnecting the remote server 106 if it is no longer needed, and supplementing or replacing the traditional routing 104 with a replicated unit connected in accordance with the present invention, stripped by the local server 102. Replicate NLM or other proprietary software, add more local servers to replicate, and/or increase remote storage capacity in the form of external storage file directories and/or "Redundant Array of Independent Disks (RAID)" units. However, the adjustment operation will typically at least involve the addition of at least one local replicating unit, and at least one remote replicating unit capable of being interconnected for operation consistent with the present invention.

Before and/or after performing this adjustment operation, the network 100 can be connected to other networks 108, including LAN or WAN, or part of the Internet or internal network through a gateway or similar mechanism, to form a wider area network of. In the schematic network 100 , a local server 102 is connected to one or more network clients 112 via a communication link or network signal line 110 . As for other suitable networks, "multi-server network" and "peer-to-peer network" are included. The plurality of servers 102 and clients 112 in a particular network can be single processor, multi-processor, or cluster processor devices. A plurality of servers 102 and clients 112, each comprising an addressable storage medium such as random access memory.

Suitable clients 112 include, but are not limited to, personal computers, laptop computers 114 , personal digital assistants and other mobile devices; and workstations 116 . Signal line 110 may be twisted pair, coaxial or fiber optic cable, telephone line, satellite, microwave relay, modular or AC power line, RF connection, network connection, dial-up connection, portable connection, and/or other data transmission "wires" or communication links of the prior art. The link 110 can be implemented by conventional or innovative signaling, in particular by a series of copy material instructions and/or data structures as described. The remote server 106 can store the replicated data obtained by the conventional router 104 on an attached storage device such as an external hard disk or RAID subsystem 118 .

Elastic replication unit system embodiment

Figure 2 illustrates an inventive system consistent with the present invention. Unlike the traditional approaches discussed previously, a system conforming to this diagram does not require a remote server. The local server 200 or other host 200 is connected to the local replication unit 204 through the local link 202 . The local replication unit 204 is connected to the remote replication unit 208 through a journey link 206 . Each local replication unit includes a spoofed packet generator for generating "pre-validated" data to the local server 200, and a non-volatile data buffer 210 for storing the replicated data until the data is stored remotely. The remote replication unit has a destination non-volatile storage device for storing replicated data received from the local replication unit 204 via the trip link 206 . The remote replicating unit can be physically separated from the local server 200 by a distance of from less than 10 miles, at least 10 miles, to at least 100 miles. This distance is an example only, as the present invention can take full advantage of journey link 206, and systems consistent with the present invention have no existing distance limitations. The flexibility of the embodiments shown in FIGS. 2 to 12 , as well as an overview of their components and operations, will be discussed in detail below for individual replication units.

However, it may be helpful to note that some embodiments of the local replication unit 204 include SCSI emulation software and/or hardware to allow the local link 202 to become a SCSI connection, thereby making the local The replication unit 204 looks like a SCSI disk or other conventional SCSI device to the local server 200 or other hosts 200 . This is accomplished by using a SCSI host adapter card within the local mirroring unit 204 and executing in target mode rather than normal active mode. Suitable SCSI host adapter cards with this purpose mode include at least an adapter card like the Adaptec 2940UWQ, and an adapter card like the Logic QLA-1040. Likewise, the local link 202 can be a Fiber Channel connection, a USB connection, a mainframe channel expander, a V.35CSU/DSU connection, an IEEE 1394 connection, a memory type (eg, AS/400 replicates memory, not disk), an IDE bus , PCMCIA connection, serial connection, Ethernet connection, FDDI connection, or other standard bus that connects the disk and/or RAID subsystem to the server. In this way, conventional replication hardware and/or software can be applied to the local server 200, so that the replicated data is only sent to the local disk, just as it is sent to a remote location through the journey link 206.

Unlike the conventional long-distance links previously discussed, the journey link 206 need not be a dedicated private communication link. Although this kind of link can still be applied in other specific embodiments, the present invention can still pass through the network, or by using such as Ethernet protocol, FDDI, V.35, or other data link protocols; IP or Other network protocols; and/or UDP, TCP, or other transport protocols on a series of networks similar to the Internet to provide the replication units 204, 208, regardless of the routing availability or non-routing of the protocol. Therefore, the two replicating units 204, 208 can be tens to hundreds of miles apart if necessary.

The itinerary link 206 can be formed by the legacy link 104, and the fraudulent local copy unit 204 as the material retrieval point. However, the journey link 206 does not mandate high bandwidth and low latency, which are generally required by the legacy link 104 . For example, unlike a SAN, a system utilizing the journey link 206 can transmit replicated data from a data source to a destination of unlimited distance. The Journey Link 206 can also provide bandwidth sharing, just like on the Internet or other wide area networks. In addition, the journey link 206 and/or the replicating unit can provide a novel system with the advantage of being relatively highly tolerant to interruptions and disconnections.

The remote mirroring unit 208 has a large buffer 212 . Therefore, the remote replication unit 208 can provide a buffer function for the complete file directory of the local server 200 or other hosts 200 . In some embodiments, the local replication unit 204 also has a large buffer. For example, in one embodiment, the file directory of the local server 200 and the large buffer (local and remote) can each hold 1 Tera byte of data in non-volatile storage. The buffering function can be implemented by using a Qlogic QLA-1040 adapter card to control up to 1 Tera byte of data, such as on the local replication unit 204 or the remote replication unit 208, substantially without additional modification. Therefore, the image file (Image) of the complete file directory of the local server 200 can be stored in the buffers of these replication units.

For increased data recovery, an optional local replica 230 can be generated; commonly referred to as a "full fill" local replica, since the file is consistent, ie available, but not necessarily up-to-date. This local copy operation can be implemented in various ways. These include, but are not limited to, utilizing another second local copy unit 204, or a second scan of a multi-socket local copy unit 204, to replicate data to a "remote" disk subsystem, and in fact geographically , the subsystem is close to the local host 200; in the local replication unit 204 the data is forked below the disk emulation layer of the unit 204 to generate another one via a SCSI or similar bus to the locally attached Disk subsystem replication (the first copy has been sent to the remote replication unit via journey link 206); or use conventional tools and techniques with the local replication unit 204 to generate and maintain the local replica 230.

The copy file 230 includes a copy of the file directory of the server 200, so that it can be restored when a hardware or software error occurs. However, because the local copy file 230 is located locally rather than remotely, it cannot provide basic protection to the server 200 against natural disasters, wars, terrorist attacks, physical sabotage, and other hazards in geographical locations. Therefore, whether or not the replica file 230 includes another replica unit 204 to implement the present invention, the replica file 230 does not provide the same level of data protection as remote replication. The locally replicated file 230 is connected to the replication unit 204 via a path 232, which may include a conventional link like path 104, or a novel path consistent with the present invention. Although the local replica 230 is not explicitly shown in the remaining diagrams, one or more local replicas may still be used in the remaining diagrams, as well as other systems consistent with the present invention.

For example, one approach is to replicate two servers using Nonstop Networks Limited or other technology; the local replication unit is used as the only (primary) disk subsystem for the second server. Another approach is to internalize all replication operations for both replication units by making the local replication unit the only disk subsystem of the host 200; the local replication file 230 becomes the master disk and makes This remote copy serves as the only true copy. The last item is a lower guaranteed configuration, but this item can still provide higher performance at lower cost.

FIG. 3 illustrates a system in which a local server 200 communicates with a local replication unit 204 over a local link. The local replication unit 204 communicates with the remote replication unit 308 over the journey link 206 . Unlike the remote copy unit 208, which has a large non-volatile buffer 212 large enough to maintain data transfers from the entire local server 200 file directory, the remote copy unit 308 only has a relatively small non-volatile buffer 310, which allows the buffer 310 holds only about a few (eg, four) megabytes of data.

However, the system consistent with FIG. 3 includes a remote server 300 with an associated non-volatile internal or external storage device. Without illustrating this point, FIG. 3 shows a RAID unit 312 that can be controlled by a remote server 300 at a certain point of the unit. The RAID unit 312 is "hot-swappable", that is, in the RAID unit 312, the failed disk can be directly removed and replaced during the execution of the computer 300; the file system structure and other data on the replacement disk data , the installation and setting can be completed automatically. In some cases, as shown by the arrow from RAID unit 312 to server 300 in FIG. part or is connected to this.

However, the RAID unit 312 can also be connected to the remote replication unit 308 and the server 300 through a dual-host connection in the configuration 1400 shown in FIG. 14 , which will be described in more detail below. The dual host connection may allow a local host to have a passive remote server 300, a remote RAID unit 312 or other remote disk subsystem used only for replication, and a local replica and/or actively servicing read requests. 200 A first "normal copy" state of the disk, switched to the remote server 300 with an unsolicited service request for data to be read by the remote RAID unit 312, or other remote disk subsystem.

In a first "normal replication" state, the remote replication unit 308 receives data from the local replication unit 204 via, for example, an Ethernet and/or TCP/IP connection 206 . As illustrated in FIG. 2, the local link 202 may be a SCSI bus, USB, fiber channel, or similar connection. Through the remote link 302 and the remote replication unit 308, the remote replication unit 308 transmits data to the remote server 300 for subsequent storage operations on the hot-swappable RAID unit 312, or if a dual-host connection 1400 is used, by Remote replication unit 308 directly sends to RAID unit 312 . The remote link 302 can be, for example, a SCSI bus connection, enabling the remote replication unit 308 to appear to the remote server 300 as a SCSI disk that can be replicated by the remote server 300 to another "disk", namely the RAID unit 312 . The remote link 302 can also be serial, Ethernet, FDDI, USB, Fiber Channel or other non-proprietary connections.

The local mirroring unit 204 has a non-volatile buffer similar to or identical to (except for specific data stored therein) the remote mirroring unit mini-buffer 310 . After the local server 200 is pre-confirmed, it is put into the buffer of the local replication unit 204 . For the primary server 200, the second "replication" write operation will only be performed locally. In fact, the local replication unit 204 has received the data and stored it in the local buffer. The local replica unit 204 stores the sector and track change data (or similar block-level data) until the local replica unit 204 can safely transmit the data to the remote replica unit 308 via the trip link 206 . The intelligent buffer of the local replication unit 204 can store any data that can be processed locally on the journey link 206 . These data will be stored on the local replication unit 204 until the remote replication unit 308 has successfully written them to the remote server 300 and sent back a confirmation signal to the local replication unit 204 . After receiving the acknowledgment signal, the local replication unit 204 deletes the successfully transmitted sector/track/block data fragments from the local non-volatile buffer. Unlike conventional systems, servers 200 and 300 are just the opposite, neither requiring standard file systems nor NLM required by operating systems or software specifically designed for data replication.

Figure 4 illustrates a system having a number of components as described above, and labeled with the same reference numbers as shown in the previous figures. However, in the system of FIG. 4, a remote replica unit 408 includes a small non-volatile buffer 310 as well as a large non-volatile buffer; the large non-volatile buffer is implemented by a hot-swappable RAID unit 312 and is directly connected to The remote replication unit 408 . The small buffer 310 is used as a buffer for the data received by the journey link 206, so that the data can be confirmed and returned to the local replication unit 204, and the data is buffered until the data has been stored by the remote replication unit 408 on the large buffer 312. No remote server is required here.

FIG. 5 illustrates some systems where two or more local servers 200 write to a remote replication unit 508 . In this figure and other figures, it should be understood that the local server 200 is used as a reference, generally including the host 200 not used as a server. In other words, the present invention can be used to replicate any host computer system 200 connected to the local replication unit 204 . The host 200 is most often exemplified by a server. But other host 200 examples include clusters of multiple computers that are not servers, mainframes, "Storage Access Network (SAN)" or "Network Attached Storage (NAS)" data sources. The local server 200 or other hosts 200 may be physically separated from each other by a distance of less than 10 miles, at least 10 miles, or as much as a hundred miles, and the like. In the system shown in this figure, each local server 200 in a specific system runs on the same operating system and file system platform, but different systems according to FIG. 5 can also use different platforms. For example, each server 200 may be a Novell NetWare server of this system, and in another system, the server 200 may also be a Microsoft Windows NT server using the NT file system.

Each host 200 in the system is connected to its local replication unit 204 via SCSI, fiber channel, USB, serial, or other standard storage subsystems or other peripheral connections 202 . The local replication unit 204 is connected to a single remote replication unit 508 via a journey link 206 . The remote mirroring unit 508 hosts the control card of each local mirroring unit 204 with SCSI, Fiber Channel, USB or the like.

Data from the local replicating unit 204 can be transferred directly (i.e., not through a remote server) to an independent hot-swappable RAID unit group 512 via SCSI, Fiber Channel, USB, or a similar connection within the remote replicating unit 508. RAID storage unit 312 . For example, the RAID storage unit 312 may be physically external to at least a portion of the remote replication unit 508 , such as the portion including the Ethernet card connected to the journey link 206 . However, remote copy unit 508 is defined in terms of functionality rather than packaging. In particular, RAID storage unit 312 is considered to be part of remote replication unit 508 unless otherwise stated (as described in FIG. 14 ). Each RAID storage unit 312 has a remote bootable disk directory, and the data is written in sectors/tracks or blocks. The remote replication unit 508 also includes a small buffer 310 for acknowledgment and buffering of data received by the journey link 206 .

FIG. 6 illustrates a system similar to that shown in FIG. 5 , but with remote replication unit 608 writing data to an external bootable disk directory within group 616 . The local server 200 running on the same platform actually writes to the local replication unit 204 and then writes the data to the remote replication unit 608 . The remote copying unit 608 has a SCSI, Fiber Channel, USB or similar control card and a bootable disk directory 614 corresponding to each local copying unit 204 . The data transmitted from each local replication unit 204 will be directly transmitted from the remote replication unit 608 to the corresponding storage disk directory 614 via the SCSI bus or other data lines. Each disk directory 614 has a remote bootable disk directory, and the data is written in sectors/tracks or blocks.

And this system roughly conforms to this Fig. 6 and in the specific embodiment of other systems in addition, also can use independent sector to preserve the duplicate data of each local server 200, and needn't duplicate data be preserved on the corresponding independent disk 614 ( That is, as shown in FIG. 6 ), or a separate RAID storage unit 312 (that is, as shown in FIG. 5 ). In various many-to-one systems, it may be necessary to activate a program that forks itself to another new connection and locks the disk directory to copy files from multiple copy attempts via IPC or other mechanisms .

FIG. 7 illustrates a system in which the remote replication unit 708 includes both the external storage disk directory 614 and the RAID unit 312 . The replicated data is stored by the remote replication unit 708 in both storage subsystems 312, 614 to provide additional assurance that the data will be readily available when needed.

FIG. 7 illustrates a system in which two or more local replicating units 204, all from a single mass storage disk directory (312 or 614 or both, depending on the embodiment) are mounted directly on a remote replicating unit 708. Depending on), the data replicated by each local server 200 is written into a remote replication unit 708, without cutting the replicated data on a plurality of remote storage units 312 or 614 as shown in Figures 5 and 6 respectively . The disk directory used by the remote copy unit 708 has sectors used by each local copy unit 204 . Each sector provides a remote bootable "disk directory", and the date is recorded on the sector/track or block in the usual way.

FIG. 7 also illustrates another system in which replicated data is backed up into two or more storage units and is directly connected to a remote replication unit that has a specific storage unit that stores the replicated data for a given local replication unit 204. 708. However, a combination of external disks 614 and RAID units 312 is used here, rather than a system using only RAID units (as shown in FIG. 5 ) or external disks (as shown in FIG. 6 ). For example, the external disk 614 holds the data transmitted from the first local replication unit 204 , and the RAID unit 312 stores the data transmitted from the second local replication unit 204 . In this system, the remote copying unit 708 has SCSI, Fiber Channel, USB or similar control cards corresponding to each local copying unit 204, and the data sent by the local copying unit 204 will be directly (that is, not to individual external hot-swappable RAID storage units 312 via a server such as server 300 , or to external bootable disk drives 614 via SCSI, Fiber Channel, USB, or similar communication lines.

FIG. 8 illustrates the system discussed in relation to FIG. 5 . However, in the system of FIG. 8, the local server 200 is executed on a different platform, as indicated by numbers 822, 824 and 826 in the figure. Of course, a system that conforms to this figure or other schematic diagrams does not necessarily have exactly three local servers 200 and their corresponding local replication units 204; the local server 200 and the corresponding local replication unit 204 are regarded as a pair, and they can be Two or more pairs. For example, a system consistent with FIG. 8 includes a Novell NetWare server 822 and a Microsoft Windows NT server 824, but another system consistent with FIG. 8 includes two Novell NetWare servers 822, 826, and a Microsoft Windows NT server 824.

FIG. 9 illustrates the system discussed in relation to FIGS. 6 and 8 . However, unlike the system in FIG. 6, the local server 200 executes on a different platform, and unlike the system in FIG. 8, the remote replication unit is unit 608, which uses an external disk drive 614 Group 616 of RAID units 312 instead of group 512 of RAID units 312 .

FIG. 10 illustrates the system discussed in relation to FIG. 7 . However, in accordance with the system of FIG. 10, the local server 200 is executed on a different platform. As shown in FIG. 7, in some systems, the local copy unit 204 may be mapped to a sector or storage unit. When mapping to sectors, the local copy unit 204 can be mapped to a sector in the RAID unit 312, to a sector of the external disk drive 614, or to a RAID unit that is also copied to the external disk drive 614 312 sectors. And when the local replication unit 204 is mapped to the storage unit, one or more local replication units 204 can send their data to the corresponding external disk drive 614 through the remote replication unit 708, and one or more other The local replication unit 204 can send their data to the corresponding RAID unit 312 through the remote replication unit 708 .

Figure 11 illustrates a system in which the material is replicated to two or more remote locations. To the extent that Figure 5-10 refers to a "many-to-one" replication system (more than one local server being replicated to a remote location), such a system can be viewed as a counterexample to the system described in Figure 5-10, And what Fig. 11 illustrates is a "one-to-many" replication system (one local server is replicated to more than one remote location). Generally speaking, the data replicated by the local replica unit 204 is the same, but using multiple local replica units 204 allows even a particular local replica unit 204 to be inaccessible through at least one route link 206 , it is also possible to continue copying without interruption. The local link 202 can also use the same or a different connection form. For example, local link 202 can be a SCSI connection and another local link 202 can be a USB connection. The journey links 206 can also be consistent or vary. Likewise, each remote replication unit may have the same components (ie, each uses RAID unit 312), or different components may be implemented in different locations.

Figure 12 illustrates a system, and similar to that discussed with Figure 11, the data is replicated to two or more remote locations. However, the local replication unit 204 of FIG. 12 is a multiplexed replication unit. That is, the unit can be connected to more than one journey link 206 at the same time, similar to conventional multi-server simultaneous connection. The multi-port replication unit 204 facilitates replication of the host 200 to multiple remote locations separated by distances or miles from each other by sending data from the host 200 via each active link. The multiplexed local replica unit 204 requires only a local buffer, and like replicators 204 in other systems, the multiplexed replicator 204 can optionally include a full local replica 230 .

Replication Unit Continuation

The components and operation of the replication unit are discussed above with respect to Figures 2-12. The additional pieces of data provided below are not necessarily pertaining to every replication unit in each system consistent with the present invention, but this additional information is helpful in understanding how replication units provide more flexibility to those responsible for ensuring that data is properly replicated people and businesses.

At least some of the replication units are capable of reliably emulating disk drives connected by SCSI, Fiber Channel, USB, or similar links to standard server drivers running on Novell NetWare and/or Microsoft Windows NT platforms. At the same time, SCSI, Fiber Channel, USB or similar emulation programs under other operating systems can also be provided.

Each local or remote control unit is configured in an appropriate manner to support I/O through a plugged-in monitor, keyboard and mouse. Certain replication units have network locations, or may allow a network administrator to access specific replication units on an adapted network 100 through a browser on a remote workstation 116 or otherwise.

Such duplication units are preferably in the form of supporting "Simple Network Management Protocol (SNMP)". Network administrators have remote access to both local and remote replication units. The replication unit 204 software may provide an interface to monitor the status of the utility. In particular, each local replication unit 204 acts as a proxy for the network, because the unit 204 can track the number of reads and writes to the local server 200, the status of each local server 200, the number of reactivation/warm boot times of each local server 200, etc. etc., and when necessary, generate SNMP traps. The local replication unit 204 can also provide the following pieces of data to network administrators: the number of blocks currently stored in the buffer 210, the warning signal when the buffer 210 overflows or exceeds a specific threshold, and the information sent by the server 200 after activation The number of blocks and the number of blocks received by the server 200 after activation.

Some local mirroring units 204 may also provide optional dial-up functionality. If a customer is using the replication unit 204 with a dial-up connection and does not want to stay connected all the time, the unit 204 provides an option to send data via the journey link 206 at specific times. At the same time, the local replication unit 204 can also be set to not allow data to be transmitted to the adjusted network 100 or another part of the journey link 206 during high traffic periods. The buffer 210 in the local replication unit 204 should be large enough to buffer data received by the local server 200 during these non-transmission periods.

Generally speaking, the local replication unit 204 preferably matches the performance of the high-speed RAID disk subsystem according to the data transmission speed, reliability and compatibility with the existing server 200 platform. Since the implementation is mostly software, it is unlikely to meet these performance goals, so the local replica unit 204 preferably includes function-specific hardware, including necessary firmware, the appropriate design and construction of which can be determined by the industry. Those in the art are particularly interested in the following: legacy copy paths 104; SCSI controllers or controllers like SCSI, Fiber Channel, USB, or the like; individual well-known subsystems such as buffers 210, 212, 310, disks 614, and RAID Unit 312 and its interfaces; software such as FreeBSD drivers; Ethernet and individually known "Network Adapter Cards (NICs)"; network protocols such as Ethernet and TCP/IP protocols; descriptions and Examples; processed with other existing or subsequently available tools and techniques, etc. to these persons.

Generally speaking, if you want to write to the local replication unit 204, you need to confirm and write to the local buffer 210, or you can write to the complete local replication disk directory 230 through the traditional path 104 or other paths, even if this local The replication method is not explicitly described in FIGS. 3 to 12 . For performance, it is generally acceptable to use the local replication unit 204, or the RAM cache in the local server 200, or both, to provide a write operation buffering function. In particular, implementations that can take advantage of existing hardware RAID unit 312 caches or other SCSI, Fiber Channel, USB, or similar caches. The read operations performed by the local replica unit 204 typically provide appropriate data from the local replica file 230 .

When the local replica unit 204 comes online again after being damaged or rebooted or otherwise interrupted, it will automatically start sending data from the local buffer 210 to the remote replica units 208 , 308 , 408 , 508 , 608 and 708 . The local replica unit 204 must not send out SCSI, Fiber Channel, USB or similar device reset signals to avoid damaging the operation of the host 200 . The data written into the buffer 210 of the local replication unit will be transmitted to the remote replication unit through the network or other journey links 206 in a "first in, first out" manner. This can be achieved using TCP/IP or another journey link protocol. The remote copy unit preferably maintains a complete, consistent copy so that the remote disk directory is available and can be mounted by the operating system at any time regardless of the synchronization state of the copy.

At least in the case of using FreeBSD-based software, the core (Kernel) problem of the local replication unit 204 is preferably not allowed to occur unless the basic replication software and hardware fail. Errors in the setting of the local replication unit 204, or any behavior of the host server 200, cannot cause the system to shut down. If possible, it is best to reset the configuration of the replication unit software without rebooting; when the software is changed, it is best to attach a unique version number. Therefore, the software preferably reads all initial information and configuration itself through a system call that can be issued by the administrator without the replication unit interrupting the data processing program. The host server 200 cannot be interrupted. The local replica unit 204 can accept writes from the host server 200 regardless of whether the remote replica unit is online or not, and regardless of whether the bandwidth of the network or other journey link 206 is available, unless the local buffer 210 has overflowed. Operation is better.

If the local buffer 210 has overflowed, it is better that the local replication unit 204 can continue to save the local replication file 230 (if it exists), and it is preferable to continue to cancel queued items by the ring queue (Queue) of the local buffer 210 . However, the local replication unit 204 preferably suspends adding queued items to the queue until the user (typically an administrator) program informs that it can start accepting queued items. Preferably a system call, rather than a reboot, allows a user-side program to deactivate or reactivate the local buffer 210 queue.

Preferably, the replication unit can automatically detect the loss and reconnection of the network or other journey link 206 bandwidth. For example, the Ethernet card of the local replication unit is disconnected and then reconnected the next day. If so, as long as there is enough space in the local buffer 210 to grasp the data changes accumulated when the local replication unit 204 is disconnected, It is still possible to maintain a state of zero data loss, and it is better not to require the intervention of network administrators.

Monitoring software for the copying unit, or a unit related thereto, preferably can determine whether the system has been completely shut down after a previous boot sequence, so that the monitoring software can determine the possibility that the remote copying of files has become asynchronous. When the power is interrupted, the local replication unit 204 preferably does not lose data as much as possible. Thus part of the duplication unit may include an "uninterruptible power supply (UPS)". It can be assumed that sometimes when a power outage occurs, write operations buffered in RAM are dumped into the local replica (if present) and/or the local buffer 210 .

In one embodiment, the replication unit operating system (ie, FreeBSD) boots from the hard disk in read-only mode to avoid problems with the file system itself of FreeBSD. Write the configuration setting data to a smaller sector, and save it in two ways, one is from the information of the same replication unit point, or send an SNMP warning signal, indicating that the configuration setting data has been missed by the replication unit and Will be offline until reinstalled. When the replication unit point cannot be accessed, the warning signal can be used. In some embodiments, the control card initialization process is also avoided, because the disk drive cannot operate by itself at this time, so problems such as bus reset can be avoided. Also, if the replication unit buffer has overflowed, it is best to only respond to the write operation with an acknowledgment signal and replicate locally, while the send buffer is already overflowing, and the remote replicated file is out of sync with the locally replicated file warning signs.

As mentioned above, if possible, it is preferable that the cold boot of the local mirroring unit 204 will not affect the host system 200, especially for handshaking signals of SCSI, Fiber Channel, USB or similar devices. The buffer 210 of the local replication unit preserves the order of write requests, and the local replication unit 204 transmits them to the remote replication unit in the same order as received, so as to preserve data consistency at all times.

The remote replicating unit receives TCP "protocol data units" (also referred to as TCP packets) from the local replicating unit 204 and writes them to the disk subsystem (e.g., external stack 614 or RAID unit 312) so that the disk drives At least in a logical "block-by-block" fashion the same as the local replica 230, if any, and the host 200 disk directory earlier. The copied material may be out of date, but must still be consistent.

In order to achieve the purpose of data restoration, the remote copy unit software preferably has a user-side interface, and this program can close or reopen the read, write, and/or remote copy file search functions of the copy unit software, so that the remote disk The subsystem, and thus the replicated data, can be accessed by a second SCSI host on the same link. Remote replication units and backup host servers are attached to the shared disk subsystem at a remote location. For example, the remote replication unit can use SCSI ID 6, while the remote server used as a restore uses SCSI ID 7. When the remote replication unit is replicating, the remote host will not mount the shared disk drive. For data recovery, as part of the switchover, the remote replication unit disables access to the shared disk drive and allows the backup host server to mount it.

Preferably, the remote replication unit can report the total number of blocks sent by the local replication unit 204 to the client. The remote copy unit copies it to the disk subsystem so that the disk directory can be mounted by the host system on the same operating system as the local server 200 that generated the local disk directory. If the remote replication unit receives a request to write to the logical block number N from the local replication unit 204 , it will write the data to the location of the logical block number N of the disk subsystem 312 or 614 of the remote replication unit. In order to maintain data consistency, write requests from the local replication unit 204 are written to the remote replication unit disk subsystem 312 or 614 sequentially in the order in which the local replication unit 204 receives the requests.

On the journey link 206, the communication between the local replication unit 204 and the remote replication unit may use the TCP protocol because of its error resilience and delivery guarantee capabilities. The remote copy unit software can be used as a TCP server; the local copy unit 204 can be used as a client of the remote unit. Preferably, the loss of network bandwidth and connection will not interrupt the local replication unit 204, nor will it interrupt the remote replication unit. Likewise, data restore operations at remote locations preferably do not interrupt the local replication unit 204 . If the connection between the local mirroring unit 204 and the remote mirroring unit is stale or disconnected, the local mirroring unit 204 can try to reconnect until the re-establishment is complete. Then, the local replication unit 204 preferably can continue to transmit the replicated material from where it was originally interrupted, or restart normal operation.

The new type of replication unit is more intelligent than the original Off-SiteServer product, because the new type of replication unit is executed on the modified operating system based on the FreeBSD UNIX operating system. One of the fixes involves changing the driver for the Qlogic SCSI controller so that the card behaves as if it were a SCSI target rather than a host, allowing it to emulate a disk drive; other controllers with appropriate drivers can also be used. The boot sequence was also modified to display the replication unit configuration utility on the console instead of a prompt, and the operating system core was recompiled. Each replication unit 204 at the source runs on an operating system that allows it to be completely independent of the host server 200 . Therefore, one of the characteristics of the elastic replication provided here is that the replication unit 204 does not require initiating or on-line software at the host server 200 (on the original Off-SiteServer product, this software uses Vinca NLM's type).

Another difference is that the operating system of the replication unit 204 can emulate a SCSI or other standard disk or data access point. Make this replication unit 204, for example, be mounted on any SCSI replication disk that supports the SCSI operating system, including at least Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows NT, Novell NetWare, FreeBSD and Linux operating systems. This disk emulation is preferably applied to any node that performs standard disk operations (at least from the server 200's point of view), including handling disk formatting of the server 200 in addition to disk reads and disk writes , Disk Partition, Disk Entire Check requests such as Scan Disk.

Systems consistent with the present invention may also maintain a fully replicated disk directory 230 in a local fashion for fault tolerance. Since the copy operation is performed by branching out the data (or performing two write operations) under the software emulation level of the copy unit 204, the copy unit 204 can use a sequence of data changes Buffer to maintain the local disk directory 230. This can enable the replication unit 204 to use the server 200 to provide services for local read operations without excessive delay, so the system can perform without causing disk failure problems, and does not need split-seek (Split-Seek) software, thereby eliminating potential software compatibility issues. This also allows the novel system to send the copied data back to the local disk of the server 200 without going through the journey link 206 under the local disk copy operation. Furthermore, if local replica 230 is already maintained, then local replica unit 204 does not need to include a spoofed packet generator to pre-confirm write operations to host 200, because local replica 230 is not affected by the travel link 206 with the transmission Effects of delays and dangers associated with copying material.

A replication unit according to the invention generally includes operating system software. Thus, at least some of the replication units may execute multiple "host" applications to manipulate the acquired replicated material. The system can also be expanded or reduced by drivers and/or appropriate software and/or hardware to meet the needs of special environments. The process can be extended to multiple processors, SCSI cards, and/or other "smart" devices to handle more operations and workloads. Likewise, systems can be scaled down to reduce cost while still meeting the needs of lower performance environments. With suitable software, the local replication unit 204 can be implemented as an independent intelligent disk subsystem, or as a local fault tolerance function to simulate the failure of the host 200 operating system. In case the intelligent disk subsystem of the host 200 is damaged, the local replica disk directory 230 can provide the fault tolerance function of the local side and serve as a substitute for the local replica.

The system maintains consistency and availability at remote locations, in part by an intelligent buffer 210 that maintains and sends data in a first-in, first-out manner. In this manner, data may be sent to the remote location in the same order as it was received via the emulation layer of the local replication unit 204 . Since packetized data does not necessarily arrive at the destination in the same order as it was sent, sequence numbers and/or timestamps may also be used.

When a shutdown event occurs, some embodiments employ ring buffers and other devices described below to protect data. In addition to using the Qlogic card as the disk destination emulator, the local replication unit has two disk systems attached via a local SCSI disk controller. A disk contains the host operating system (ie, FreeBSD) on it, as well as related utilities and replication unit management software. This disk also serves as the buffer 210 disk. Another disk system attached to the replication unit is at least as large as the host 210 disk being replicated and serves as a local copy of the host 210 disk.

SCSI data is read by the Qlogic card and evaluated in the kernel according to read and write requests. Read requests from Qlogic cards are preferably processed locally on the replica disk 230 rather than traveling across the network 206. The write command is directly copied to the local copy disk 230 as soon as possible, and confirmed to the host system 200 (but not necessarily pre-confirmed), and added to the buffer disk or the ring buffer of the non-volatile RAM.

Every time when a block is to be written into the ring buffer, two blocks are actually written in order, one is the actual data block to be transmitted, and the other is the current end pointer of the queue. Timestamp, or further data such as LBN (Logical Block Number). The latter block is the so-called "Meta-Data" block. This method is not space efficient, but it reduces the number of disk reads and writes required while maintaining queue pointers. Queue pointers can also be maintained by keeping at least one copy if RAM is available, or by storing the entire ring buffer in non-volatile RAM. One way to save both space and time is to write a large chunk of data to the ring buffer at a time, buffering the chunks in memory until enough is accumulated to perform the write operation. This allows the hyperblock to be used by multiple data blocks, reducing the number of disk write operations and saving disk space.

When a shut down event occurs and the machine is restarted, the head end of the queue can be found by searching the latest time stamp in the hyperdata section, and then the position of the tail pointer can be determined by using the hyperdata section. For example, this can be achieved by performing a binary search method. Since the buffer is implemented in a circular fashion, it is not necessary to actually remove the transferred data from the buffer (ie, delete or zero it); this can be done by incrementing the tail pointer. When the head pointer is less than 1 than the tail pointer, the state of buffer overflow can be detected. The pointer points to the location of the ring buffer, not to the data values of the buffer (this is a matrix rather than a linked list).

Since there is a recent number of seconds before the system shutdown, which is sufficient to determine the last block location written, it may not be necessary to keep the 64-bit timestamp. For example, suppose four blocks were written in the same second and have the same timestamp. Then, because of this bit-ordered queue, the last block according to the timestamp is the last written one. If time stamping consumes too many computing resources, then a simpler counter may suffice, although it will complete the lap in less than 2038 AD. The size of the queue buffer will vary with the end user's data change rate and the length of time required by the client, so as to withstand the problem of network 206 interruption. The queue buffer can be as small as a few hundred Megabytes, or as large as the host disk directory being replicated.

There is no set minimum or maximum limit on the size of the buffer, and when high data rate changes and frequent lengthy interruptions are expected on the journey link 206, the buffer will likely need to be larger than the capacity of the host disk directory being replicated Even bigger.

A separate process, which can be executed on the client side or the system side, reads the blocks from the ring buffer and sends them over the network 206 to the remote replication unit. The transfer program can keep the queue handler informed of the current pointer position of the transfer program, and can observe timestamps to determine when the queue is clear. If the tail pointer stored in the hyperdata is only slightly out of date, it is still acceptable, because in the worst case, as long as the number of retransmitted blocks does not accumulate into excess when the system is reactivated, the system will Will retransmit data blocks with the number of data blocks that have been sent out again. Preferably when the server is activated, the transfer program can also determine the number of blocks. In some cases, it can be presupposed that the buffer will be able to buffer the entire host disk capacity. Under this "do no harm" philosophy, it's best not to risk any slowdown of the SCSI bus performance, and just dump the data that doesn't fit into the overflowed buffer, and notify the client side to monitor it. event program.

In an attempt to reduce the number of resent blocks, the system checks writes against the local replica and only adds them to the ring buffer if they differ, avoiding any lazy writes. This can be done by maintaining a hash table (Hash Table) that checks the sum of each LBN on disk; the trade-off is that the processor spends time calculating the check sum, and memory or additional disk operations.

Methodology

13 and 15 illustrate the method of the present invention related to remote data replication. Some methods include the step of installing a replication unit; these steps are collectively combined as installing step 1300 for simplicity. For example, system integrators, replica device vendors, and administrators may be authorized to perform some or all of the steps shown in step 1300 when performing any of the system installations shown in FIGS. 2 to 12 . Other methods of the present invention also include the step of transmitting data to one or more copying units; for simplicity, these steps are collectively combined as a transmitting step. These transmission steps may be performed with test data under the authorization of the installer as part of the installation step 1300, but these steps may also be used in a routine manner in accordance with normal user requirements of systems consistent with the present invention. Work is extremely critical data to perform.

In the connecting step 1304 , at least one server 200 is connected to at least one local replication unit 204 . As previously mentioned, the connection may be in the form of SCSI, Fiber Channel, USB, or other standard disk subsystem bus. Since the local replication unit 204 can emulate a disk subsystem, connecting at step 1304 is basically the same as connecting the disk subsystem to the server 200 , at least from the perspective of the server 200 . In particular it is no longer necessary to install special NLM or other replication software.

In the connecting step 1306 , at least one local replication unit 204 is connected to at least one corresponding journey link 206 . Depending on the situation, many operations may be involved. For example, if journey link 206 comprises a local area network, then local replication unit 204 can be connected to the network like any other node; SNMP support can also be installed. If the journey link 206 includes a dial-up connection issued by the local replication unit 204, the parameters of the dial-up connection can also be set. Likewise, if journey link 206 includes a dedicated private communication line, such as a T1 line, then similar operations can be used to make the connection.

In the connecting step 1308 , at least one remote replication unit 208 , 308 , 408 , 508 , 608 or 708 is connected to at least one corresponding journey link 206 . Typically this can be accomplished in the same manner as the local replication unit 204 was brought online in step 1306 . However, in certain embodiments, when the remote replication unit acts as a TCP server, the local replication unit 204 becomes a client of the remote replication unit. Thus, in such an embodiment, the connecting step 1306 is connected to a TCP client, and the connecting step 1308 is connected to a TCP server.

In a testing step 1310, testing is performed on the replica unit. These tests may include, for example, comparing the output performance of the local replica unit 204 with RAID unit performance; re-replicating data from a remote location back to the local location; putting improperly configured information back into the local replica unit 204, and then correcting the information ; reboot the local replication unit 204; disconnect the journey link 206; interrupt the power supply to the local replication unit 204; interrupt the power supply to the remote replication unit; overflow the buffer 210 of the local replication unit 204; and other tests. In particular but without limitation, this testing step 1310 may involve performing one or more of the tests of the "Test Combinations" section herein. This test step 1310 also involves the transmission of data related to step 1302 described below, but for simplicity, the test is only shown as a single step in FIG. 13 .

The transmitting step 1302 may also include a transmitting step 1312, in which the server 200 transmits the data to the local replication unit 204 through the standard bus. This is achievable because the present invention, unlike conventional path 104, provides replication units capable of emulating a disk or RAID subsystem.

In the transmission step 1314, the copied data is transmitted via the journey link 206. As before, this can be done as a dedicated link like conventional path 104, but can also be done via, for example, an open standard protocol like Ethernet, and/or TCP, and/or other open standard protocols, including the related similar Traditional network architecture infrastructure like LAN and/or Internet.

In some embodiments, the replicated data is time-stamped by the local replication unit 204 to maintain a sequential record of previously replicated data blocks and also associate the data to a specific point in time. This would be accompanied by remote and/or local data storage devices large enough to hold one or more replicated disk directories, plus snapshots of incremental changes to the disk directory's sector/track/block level (Snapshots ) instead of just grasping the current replication disk directory replication. In a more convenient embodiment, only one snapshot is required. This single snapshot provides a baseline, and subsequent changes are logged so that the state of the disk directory at any preset point in time (depending on the time granularity of the log) can be restored. The log can be of any size. If necessary, additional storage space can be added to maintain the file. Of course, it can also be designed as a fixed-size FIFO ring buffer. When the original log buffer is full, the old items will be replaced by new items. to overwrite. In general, suitable replication software, coupled with snapshots and (if necessary) incremental changes, can later be used to restore the replicated disk directory as it existed at a specific point in time earlier.

In a transmission step 1316, the replicated material is transmitted to the serverless replication unit. This configuration can be illustrated in Figure 2. A remote replication unit is not a traditional server, although it has the same hardware and features. The server can provide more general functionality than the replication unit; the replication unit is focused on efficiently providing essentially continuous, near real-time replication of remote data. The behavior of the remote replica unit is similar to that of a remote replica server in terms of accessing data via the journey link 206, but otherwise very similar to a mounted disk. In particular, the remote replication unit behaves like a disk or RAID unit to the second server, if one is attached. If re-replication is really necessary, the remote replication unit does not need a second server, and re-replicates the data back to the local server 200 through the journey link 206m.

After the data is transferred by the local replication unit 204 to the destination remote replication unit, the remote replication unit may perform any processing. For example, the remote mirroring unit may convert received data packets into only data blocks that can be written to a single external disk drive 614 . The remote replication unit can also convert the received data packets into data blocks, and then write them to the internal disk subsystem and/or disk sectors. The remote replication unit can also receive data packets, convert them into disk data blocks, and then strip the data to multiple disk subsystems of a "non-intelligent" disk subsystem by means of internal stripping (Striping) software (RAID). disks and writes to RAID unit 312 in the style of an external data subsystem. This same process of converting packets into disk block data and then into stripped (RAID) data is accompanied by a program stored in an external non-intelligent disk subsystem, which can be processed by a hardware control card and related drivers. The remote replication unit can also be written to the external intelligent RAID subsystem 312, and its disk blocks are written into the disk subsystem in the form of data streams, and stripped by the intelligent RAID subsystem.

Instead of directly writing the received data to the replication unit 312 or 614 immediately, first the remote replication unit can write the data into the remote buffer, and then send back an ACK confirmation signal in the form of some material "signature" (such as a sum check or is the CRC value) to the local replication unit. The local replication unit will then confirm the result according to the signature, either "acknowledgement-acknowledgment (ACK-ACK)" or "acknowledgement-rejection (ACK-NAK)"; Only when there is an incoming ACK-ACK, the remote copy unit will receive data from the remote buffer and write to the remote copy file. In this embodiment, if the remote replicating unit not only receives the data but also receives the original signature from the local replicating unit, then the remote replicating unit rejects the original data transmission if the original signature is not properly authenticated .

In addition, the data can also be confirmed in different ways. For example, a remote replicated unit and a local replicated unit may be considered endpoints rather than subsystems of each other. In this case, on the remote copying unit, the ACK signal is sent by the remote copying unit itself (perhaps by its cache); on the local copying unit, the ACK signal is also sent by the local copying unit itself (at last preferably sent by its cache); but on the part of the local copy unit, the ACK signal does not need to come from the remote copy unit, but only by the local end of the journey link before sending the ACK signal to the host. Before the local replication unit deletes the data block in the local buffer, it still needs to carefully wait for the ACK signal sent by the remote replication unit, but this can be done after confirming to the host.

Additional steps can be performed if there is at least one second server in the system. For example, the remote replication unit can directly relay the data to the remote server 300 through the server's network operating system. The operating system can be active or passive. In both cases, data received via connection 302 can be written to an internal local disk subsystem by the operating system of server 300 . This approach requires a specific software for each operating system at the remote location. The remote replication unit can also use an Internet-style data window to transmit and receive data between the remote replication unit and the second server 300 . The data window can be extended to the browser interface by a plug-in, or extended to the core operating system by Internet components, such as Microsoft ActiveX extensions.

In any of the above situations, the local replicating unit may be sufficiently "smart" to relay replicated data to a single remote replicating unit or to multiple remote replicating units; a "one-to-many" system as shown in Figure 12 , with three remote replicating units connected to a single multicast local replicating unit 204 by respective journey links 206, and the multicast replicating unit can also be used alone or combined with a single replicating unit for other conforming In the system of the present invention. There is no hard limit to the number of remote replication units on a given system.

A remote replication unit may also relay replicated data to a nearby replication unit, and/or to another remote replication unit for fault tolerance reasons. A remote replication unit may serve as a headend between two or more remote replication units, properly monitoring the continuity and integrity of replicated data to balance its load and provide fault tolerance. Connect N remote replication units to each other and maintain the same network location or Domain Name System (DNS) name to provide further fault tolerance. Of course, the above methods can also be applied in combination.

In embodiments having one or more individual, completely independent remote disk subsystems connected to the remote mirroring unit, the remote mirroring unit behaves, for example, like a SCSI master and writes data to the remote disks. If there is a second server 300, the server 300 follows the remote mirroring unit and the remote disk subsystem in the SCSI chain. During the data copying process, the second server 300 is generally a slave and/or is in a passive state. In case the replicated remote server 200 breaks down, the remote server 300 mounts the external disk directory and becomes the SCSI master. At the same time, the remote copy unit unmounts its remote disk subsystem disk drive and becomes passive.

In particular, this can be accomplished using a configuration similar to that of FIG. 14 , which includes a "dual host" connection 1400 . In many traditional ways, only one host adapter card will be activated in the SCSI chain, usually set to LUN7. When powered on or reset, the host polls all other LUNs to determine which devices are attached. If the system uses an adapter card suitable for dual hosts, the second host is generally set to LUN6, and only reset or query LUN0-5. This should make LUN7 primary and LUN6 secondary. In any case, if connected in the manner shown in FIG. 14, the two hosts can access the lower-level target device.

Dual host connections are not new in themselves. In particular, dual host connections with BusLogic EISA cards and Novell NetWare servers are known. However, the functionality provided by the dual-host connection cannot be used in this case because the Novell server cannot update its profile configuration table on a request-by-demand basis. General information on dual host connections is available from open sources, including an online SCSI FAQ. If do not use dual host connection, then remote server 300 needs a driver program NLM, and/or other software dedicated to duplication, so that this remote server 300 can receive duplication data directly from the remote duplication unit place, and it is stored for follow-up use.

In an embodiment consistent with the present invention and using dual-host configuration 1400, remote replication unit 208, 308, 408, 508, 608, or 708 controls RAID unit 312 or other remote disk subsystem until commanded to stop to perform Toggle action. At this time, the remote copy unit executes the remote data copy operation, and as described in the text, as the SCSI master, sends the data to the RAID unit 312 . Meanwhile, Novell or other second server 300 is still in a passive state. This prevents damage that may occur due to concurrent write operations to the server 300, remote replication unit, RAID unit 312, or other remote disk subsystems in a "two-to-one" manner as shown in FIG. 14 .

For switching operation, the remote replication unit unmounts the RAID unit 312 disk drive, and the server 300 mounts the RAID unit 312 disk drive. Then, the server 300 becomes a SCSI host. Since it is generally impossible to predetermine or force the selection of the second server SCSI adapter card, it is better for the remote replication unit to have a second host location (LUN6). After both machines are powered on, the remote replication unit senses a second reset when the disk drive is powered on. This is normal, but the remote replication unit should be recoverable at the device disk drive level. Note that with the dual-host (not dual-channel) approach, the wiring is a normally terminated SCSI chain; no additional hardware is required. Switching operations can be performed entirely by software through storage subsystem and/or disk drive unmounting, mounting, and related operations.

The foregoing discussion can be regarded as a preset one-to-one relationship between the remote replication unit and the second server 300 . However, software or a mechanical SCSI switch (for example) can be used to provide the connection between the remote mirroring unit and a plurality of potential host servers 300 . In protocols like Fiber Channel and/or SAN architectures, there is no traditional SCSI master-slave relationship. Instead, there is an address relationship that occurs through DNS and/or digital location. In such a system, the switching operation can be switched by changing the location, while the remote mirroring unit remains passive.

The remote mirroring unit can be configured to run a complete network operating system. In the event of a disaster, the remote replication unit enters an active state and becomes a fully operational server for information on the disk subsystem to which the replicated data is to be transferred. The remote replication unit can also execute an emulation program to emulate a server under a specific host operating system at the local end. The remote copying unit can also execute a program to shut down the operating system and any related programs used for copying, and then reactivate it under the specific host operating system from an additional internal disk or sector.

The remote replication unit can also be enhanced to continuously serve as a second server, rather than being generally used for data replication. However, doing so will severely degrade replication performance and increase the risk of replication failures.

If the software of the remote copying unit is substantially the same as that of the local copying unit 204 , then the remote copying unit can be used as the local copying unit 204 . For example, when the replication is from A to B and then to C, the replication unit at B is a remote replication unit relative to A, and a local replication unit relative to C. The remote replication unit can also serve as the local replication unit 204 when restoring from the remote location back to the source. That is to say, when going from A to B, the replication unit of A is local, and the replication unit of B is remote, but when going from B to A, the replication unit of A is remote, and B is remote. The unit of replication for is the local side.

Finally, some modern systems can accept multiple user sessions; a user session is a replication data relay or storage session. Multiple combinations and examples of the above-mentioned scenarios can appear simultaneously or individually in a suitable state. At the same time, more processors including disks, memory, etc. may be required to complete a specific combination.

These various tools and techniques can also be applied to one-to-many or many-to-one replication systems consistent with the present invention. Likewise, discussions about packet, IP, Ethernet, symbolic ring, or other packetized data environments, and it should be understood that other supported environments can also use streams instead of packets Data is written.

Except in cases where a certain step requires as input the results of another step, the above and other steps may also be performed in different order and/or concurrently. For example, connection steps 1304, 1306, and 1308 may be performed in different orders and/or simultaneously, but in test step 1310, it is assumed that some or all of the respective specified connections are present, at least in name. Step 1312 transfers the data to the local replica unit, necessarily prior to step 1314 transferring the data via the journey link 206 or to the local replica 230 . On the other hand, if the transfer is to a serverless remote replication unit, the transfer step 1316 can be performed in the manner of the transfer step 1314 . Regardless of whether it is expressly omitted in this detailed description section, other steps can also be omitted unless it is in the stated claims. Steps may be repeated, combined, or named differently.

Referring now to FIG. 15 and the following description, which will refer directly to that figure while discussing additional tools and techniques that may be advantageously employed (alone or in various combinations) within embodiments of the invention, such as local- Remote role swap, implementation of hot standby server status, several alternative buffer contents and buffer rules, transactions, many-to-one copy processing (simply explained in the previous article according to Figure 5-10), identification of frequently accessed data processing, and use of secondary servers in an unauthorized manner, etc.

role reversal

When a master server, such as server 200, becomes non-operational, and has fully sent the changed data to the remote location, the replica units, such as units 204 and 208, can change roles, thereby allowing the servers on the WAN, such as The remote server of 200 can provide functions such as disaster recovery for each network node. Assignee MiraLink's first patent, US Patent No. 5,537,533, discusses a continuously available, remotely replicated, replacement network server. But obviously there is no discussion about role swap availability. In a role reversal, the entire replication unit architecture is reversed by its nature. If both the local and remote replication units can survive any event that requires a disaster recovery function, after the local-remote role is reversed, the original remote will be regarded as the local end, and the data noted there Changes are replicated and sent back to the original local side, which is now a remote role.

In one embodiment, the role-swapping step 1506 is implemented in the following manner. First, it is best to configure sets of "box" pairs (such as duplicate units of units 204, 208) identically to facilitate conversion operations. Second, the core module that handles SCSI emulation will be active in the local box and dormant in the remote box. It is this software state that actually produces the "media not standby" feature described below. After the local box has submitted all the change data to the remote box, the user can issue an instruction to perform role swapping. This turns off the replication function of the local box and activates the remote SCSI emulation layer so that the remote server can now be directed to register with the remote replication unit. In this way, the replication unit at each station can change its role and involve the permission server to effect this change. The current role of the replication unit may be indicated internally by means of flags or other variables.

Here, when the replicating unit switches roles 1506 and begins to operate in the remote role, a physical disk as the transmission medium in the replicating unit operating in the local role can be used as a receive buffer. In a locally replicated unit, such as unit 204, the disk is a transfer disk that stores change data for the journey link 206. At a remote replication unit, the same disk would be a receive buffer that holds received 1504 change data until it has been identified and delivered to the remote replication unit disk or other non-volatile storage. In some embodiments, the recognition level and delivery time delay are programmable.

Media not ready for the second server

Using 1508, the "media not standby" state allows the second server 300 to be in a "hot" standby mode. Without this, after the remote copy unit 308 is indeed on-line, it may be necessary to bring up the second server so that the second server can query the SCSI chain to see if the remote copy unit 308 is present. In step 1508, the SCSI emulation layer of the remote mirroring unit responds to the request from the remote server 300 with data characteristics such as data size and data availability, but denies the remote server 300 access to the data content . Here, these restricted responses to server 300 would be provided by unit 308 using the standard SCSI response format.

Alternatively, the second server 300 can be brought up without the remote replication unit 308 being cabled to the second server 300 . After a final failure, the cable is connected and a SCSI device chain discovery operation must be performed to detect new hardware. The server 300 then registers the device 308 . In contrast, using a preferred mode of 1508, a media unarmed mode is used, and the capacity 308 becomes "enabled" and "detected" but remains unregistered until the request expires.

ring buffer

Two additional modes of operation can be implemented by allowing a "non-consistent" replication mode (i.e. no longer fully reliable time-delayed replication), whereby recovery operations can be performed at a given time and/or bandwidth The availability of the circular data queue within the buffer is extended. This ring queue is also known as a "Scalable Smart Buffer", "Ring Buffer Queue", or "CBQ". This would use disk space as a FIFO (first in, first out) in a normal mode, storing changed "Logical Block Numbers (LBNs)" instead of storing actual changed data. This means that the storage size can be reduced by CBQ (128LBN "4 bytes each" compared to a change data block "512 bytes each"), thereby slowing down the speed at which the CBQ is filled up for the journey link 206 More recovery time. If the journey link 206 remains down for a long enough time, and the CBQ becomes full, a full replication will be required. However, the system only needs to restore the changed blocks once, so that CBQ will collapse in a virtual "file allocation table (FAT)" or similar block (such as cluster or sector) configuration structure, and for each block The block stores the checksum or "ring redundancy check" value in the CBQ. After the journey link 206 is recovered, the remote copying unit will be notified 1302 by the local copying unit that it needs to re-copy, and it will exchange blocks such as CRC with the local copying unit for deciding which cluster of the disk needs to be sent (for example ). For example, more than 90% of the hard disk may not have changed, so there is no need to send it through the journey link 206, which is indeed different from the previous replication method, which assumes 100% of the data between the local and remote drives different.

SCSI probe buffer handling

In some specific embodiments, the "scalable intelligent buffer" (i.e., "ring buffer queue") in the normal mode will store the changed blocks until a threshold is reached, here At this time, the replication unit will store the 1510 change "Logical Block Number (LBN)" instead of the real change data. In a variation using "SCSI snoop buffering", the data replication system buffers the actual SCSI commands, rather than cutting out the block data, and buffers the SCSI commands. This can be done in the following manner; note that, as shown in FIG. 15 , different embodiments of step 1512 may include or omit one or more specific operations collectively referenced here as section number 1512 .

A target adapter within the replica device 204 passively listens 1512 to the SCSI bus. "Passive" herein means that the physical device 204 does not electronically participate in the bus, but does record 1512 what it observes on the bus. The target adapter can utilize existing physical hardware of a similar nature to that used in SCSI analyzers, but is not intended to do so. SCSI Analyzer is an analysis tool that allows users to monitor SCSI bus activity without actually participating in it. The data collected 1512 from the SCSI bus by the target adapter of the present invention is then interpreted 1512 with respect to activity originating from or towards a particular real participant or "target" on the SCSI bus. This profile includes a set of encapsulated SCSI commands, ie, 1512, as seen on the SCSI bus.

Command pairing 1512 filtering criteria, ie commands related only to desired SCSI bus participants, are queued 1512 in the order observed using appropriate buffering algorithms. Here, it is not necessary to analyze or interpret 1512 data collected from the SCSI bus beyond identifying 1512 commands or responses from a particular participant on the SCSI bus. However, operations may be taken to split 1512 into (a) requests from a host controller on the bus, and (b) commands of a write nature from a host controller on the bus. By means of buffer 1512 write property commands, the buffer may contain only transaction entries related to the change data of the target participant on the SCSI bus.

The buffered SCSI command data is then communicated 1502 to the second replication unit 208, 308, etc. across a communication link such as the journey link 206. Upon receipt 1504, these commands are "played back" 1514 by being repeated on a second entity individual SCSI bus by equal or similar participants following the same protocol as their peers on the first bus. The state starts. In this way, when the 1512 commands are read from the original SCSI bus, the copy target participant on the second SCSI bus can be set to the same state as the original target participant, and make it contain the same material. Here, other buses than SCSI can be used in a similar manner for command capture and playback, as well as other features of the present invention.

When implementing the replication system, it is important to be aware of subtle inadvertent interactions between read requests and write requests. This is especially important if the SCSI bus participant in question maintains an implicit, but not immediately visible, internal state that changes its behavior in response to a subsequent write operation following a previous read operation.

In addition, errors reported from participants that capture commands on the monitored SCSI bus need to be handled 1514 in a manner consistent with that on the second SCSI bus, but this does not necessarily result in the same errors. Meanwhile, an error condition generated on the second SCSI bus may cause the status and data of the second SCSI bus to be inconsistent with the first SCSI bus.

Temporary deal

Temporary transaction processing 1516 utilizes a replication unit 204, 208, etc. buffer to provide transaction file system functionality. Note that different embodiments of step 1516 may include or omit one or more specific operations, collectively labeled as part number 1516 . File opening and closing, and file operation timestamp memory can be tracked 1516 by operating system agents and/or kernel embeddings to support roll-back 1516 on file systems that do not yet support transactional operations.

In this context, a "kernel embed" is a binary patch or a source code patch that embeds existing binary code or source code to modify the operating system. This is different from a device driver or agent, because the core embedded file insertion operation will occur in the operating system, and is not specifically designed to allow additional software to be linked into or otherwise inserted. These events can be followed by inserting 1516 program code at points in the operating system where operations such as opening and closing files occur.

This approach can be thought of as a hybrid of copying and overwriting, since overwriting copies the file when it is closed, and copying copies the file when it is written to. This approach attaches 1516 a time stamp or other label to the copied material depending on when the file was opened or closed for waiting. In this way, all changes made by a program after opening the file will be linked 1516 to the open/close cycle, while any subsequent changes after reopening the file will not be linked to the current cycle .

When opening/closing is done, lack of space or other factors may make it difficult to track 1516 specific blocks associated with a file, but can then keep track of 1516 the precise time when a particular opening/closing event occurs, and can also track 1516 The precise time when a block entered the buffer. Thus, at a later time, the system administrator can review the open/close log files provided by the insert and selectively eliminate changed data blocks matching a specific time period.

Note that this approach provides only relatively small benefit when applied only to applications such as databases that open files for a long period of time and write data to them for a long period of time. However, it works quite well for keeping a file system safe or for restoring 1516 word processor files that were accidentally overwritten, since these operations occur in a short period of time, usually as quickly as possible . Here, a file system change is tracked 1516 to a reasonably precise point in time as it occurs, eg, a file storage operation in a word processor. The data change copy operations corresponding to these points in time are then identified 1516 and selected from the stream of data change operations performing the copy operations, and the selected data change operations are edited 1516 .

The transaction 1516 can be done by a remote system agent, or other program that maintains 1516 a log file of data changes in a buffer and can backtrack 1516 the changes for a period of time. The remote system agent resides in a remote data replication unit such as unit 208 and can receive 1504 , 1506 data change information from the local data replication unit 204 over communication link 206 .

In some embodiments, the system has a replica disk and a buffer disk installed both locally and remotely, but unless the remote system no longer needs to be remote for some reason and becomes local, ie Remote buffer platters such as buffer 310 are not actually utilized as when the remote/local roles are swapped 1506 so that the remotely replicated data can be restored back from the replicated location. Thus, a remote buffer disk may be utilized to save 1516 the transaction log file.

These log files can be organized in a structure similar to a transaction queue, which can store 1516 a block of data and information about it (LBN and timestamp) in an ordered fashion. Data is not written to disk immediately, but instead the present invention stores 1516 it in a buffer for a period of time determined by buffer space availability, and/or administrator preference. When the time expires, data is removed 1516 from the buffer and written to the duplicate image. But at this moment, the manager will not have the option to undo (undo) the writing. And if the remote 208 needs to become 1506 the local 204, then the entire remote buffer 310 will need to be transferred to a disk, such as a RAID, before the same buffer space 310 can be assigned to the data transfer operation Unit 312.

More broadly, by utilizing the buffer and its timestamp information, effectively redoing 1516 has occurred both at the replicated server 200 and at the remote system buffer 310 receiving the replicated material, but has not yet left Transactions on the RAID unit 312 are stored out of the buffer 310 of the replicated image. This redo operation can be performed by the manager using a management utility by simply moving 1516 the queried blocks off the remote queue.

Alternative Buffer Law

Different buffering algorithms can be used in some replica units 204 to save buffer space and time compared to simple ring buffers. The assumption is that blocks are written to the local replica 230 when received and only the LBN number is stored in the ordered queue. That is, as used herein, the so-called "ordered queue" refers to any queue (queue), serial (list), "first-in-first-out (FIFO)", form (table), or other Retrieves one or more collections of data structures in the same order. In particular, a circular queue is an example of an ordered queue.

In the case where the copied block is overwritten on a block that already exists in the queue and has not been copied 1302 to the remote station, the pre-existing block will be copied in the same manner as in the previously described embodiment. Blocks are copied into the buffer space (ie only a pointer to the block is placed in the real queue, and the block itself is stored in a swap space). This alternative buffering algorithm allows the entire buffer to be "lite" while still maintaining safety. Here, only the moving parts of the changes are buffered.

"Compact mode" and "normal mode" refer to buffered mode. Compact mode implements a "best effort" strategy, which occurs when the buffer is filled. Normal mode is the usual buffering mode until administrator-defined or other thresholds of free buffer space are reached. Semantically, this threshold is sometimes called the "high water mark" because when the water level is high, it's best to handle it. After this threshold is reached, the buffer operates in compact mode, which no longer guarantees data integrity in all cases, as it only saves the LBN tracking 1510 changes, not the LBN and data . Here, data will be written into the local copy 230 in the normal way, and when the LBN is read from the queue, the data to be transmitted 1500 will be read from the local copy 230 . In many cases this works fine - all data is copied.

However, in some cases files are written and then re-written due to some changes. Both changes will be put into the queue, but when the first change is removed from the queue, the delivered 1500 data is actually from the second (or latter) change, and will therefore be returned when the time is up. Previously appeared on remote replicated discs 310/312. This can be a significant problem, as this usually overwrites the filesystem object. But it's a "try it and it might work" rule and still provide some level of protection, so it's better than just running out of buffers.

The alternative buffering algorithm of the present invention, which improves this approach, proceeds in much the same way. However, when a given block of data is subsequently written, the block on the local copy 230 is copied and stored somewhere else in the buffer. It is not feasible to insert this block back into the queue; in general, too many queue elements would need to be moved to make room. However, the location of individual entries for that particular LBN can be changed to reference a data block at some other location on the system. For example, the local replication unit 204 may use a second storage area to store the blocks.

An advantage of this alternative buffering strategy is that most of the time only a single write operation is necessary. Occasionally a read/write/write operation 1518 is required, i.e., read the block from the local copy 230; write it to temporary storage; update the LBN entry in the queue towards the temporary block in permanent storage, but not in the copy; write the new block into the copy 230 where the previous copy of the data would have been stored; then add the LBN entry for the new block to the queue Inside.

Remote many-to-one replication

This new approach includes the technology described herein, which can be further adapted to provide a hardware/software platform as a many-to-one solution with a central backup site or service provider as previously described. The local system works as described above. The local replication unit 204 is connected to the host server system 200 via the SCSI bus and appears as a fixed disk drive, which in turn can be used, for example, as part of RAID-1 replication. Data is then transferred 1500 from the local buffer 210 to the remote station via the local replica unit 204 transport protocol, the operations of which can be as described elsewhere herein. A management interface may support a one-to-one view (from the local replica system's point of view) between the local system and a remote many-to-one solution within a replica unit such as unit 508, 608 or 708.

The remote many-to-one solution can execute 1520 multiple embodiments of the replication system's transport and buffer management software, eg, multiple software embodiments of the remote replication unit 208, 308, 408 software described above. However, in these embodiments, the core module is replaced by a user space control module, which emulates 1520 the core interface of the aforementioned system. Multiple "virtual remote replication units" (also referred to herein as "virtual systems" or "virtual 1.1 systems") can be hosted on a server 300 hardware platform, or on modified replication units 208, 308, 408 Execute 1520. The hardware platform can be any high-end server system that can provide a shared and available Posix/Unix/SRV4 environment. Examples include, but are not limited to, Sun or IBM servers running Solaris/Linux or AIX/Linux, respectively.

To facilitate the implementation of virtual system delivery software that can function 1520 as desired, the software should be written in a modular fashion without making any assumptions about how data flows between devices containing, for example, a local buffer, a remote buffers, a local copy, a remote copy and the core. Control over where data comes from and where it goes is through the core interface, which maintains state information about replication and user activation status changes.

In some embodiments, the hardware platform executes a SAN management software interfacing with a replication unit management layer to provide functions such as routing devices on the SAN storage of local devices as needed, implementing (for buffer devices, replicator, change replicator, etc.) various operating states. The management interface of the many-to-one system may be derived from the previously described management interface of the replication unit through MIB extensions and the World Wide Web using SNMP. Within this management layer, a one-to-one relationship can be provided by the primary (local) replication system, while still allowing the required state operations on the remote system. Here, a SAN management suite can be used as a model for similar interfaces, such as setting checkpoints, making multiple copies of replicated data, and/or changing devices that will be replicated.

Identify frequently accessed data elements without applying specific knowledge

In this section and the following two paragraphs, a data block is an example of a "data element", and a disk section is an example of a "storage unit". A "current collection" can be viewed as an abstraction of a player.

A common problem with fault-tolerant systems is that the application does not take steps to recover when only a portion of a set of data storage operations completes before the application terminates. Applications that are designed to be fault tolerant typically have methods whereby a set of data storage operations can be performed, but these operations are not considered valid until some final operation is performed, thus if If either operation is unsuccessful, the entire operation will not be considered valid. However, many applications are not designed this way.

A method for providing fault tolerance to applications that are not specifically designed to have application-specific information that contains detailed knowledge of the operations to be performed and to keep track of the application state outside of the application . If the entire transaction has not been delivered by an external agent monitoring the application, it may be removed from the role data set. But this creates problems because the monitoring agent needs specific knowledge about the application's behavior, so this can be extremely sensitive to changes in data outside of the application itself.

One approach described herein is to frequently identify 1522 received data using a monitoring agent that does not possess such application-specific information. The agent assumes 1522 that a set of store transactions for the application would occur in a temporally related cluster, assuming this would normally group a set of operations on a first group of contiguous data components, assuming the store operations would occur in The set of operations before and/or after the set of operations on the first group of contiguous data elements, and assuming that these store operations will occur at or near a second group of contiguous data elements, which are located in addition to the first group of contiguous data elements In other locations, and shared by different exchanges. These shared components are referred to herein as "state blocks."

For this example, consider a file system write operation. The data file is updated through a set of one or more operations, usually involving a set of contiguous storage components disposed adjacently on a physical storage medium. These file system tables are then updated, which will be stored in different but consistently referenced locations, and will be located in a limited set of entity-related storage components. each segment or cluster holding user data for the file corresponds to a contiguous data element of the first group, and each segment or cluster holding the file system table, bitmap or similar file system data structure, is the adjacent data element corresponding to the second group.

Many applications can support a write strategy similar to this. To increase write performance, a given operating system may attempt to cluster unrelated write operations into a single write operation. Therefore, the data file update operation will be performed at a time determined according to the operating system.

With the present invention, a method for identifying 1522 a transaction is to keep track of storage write operations between update operations to these special state blocks. A transaction will contain all data written to the data file(s) between two state block update operations. Identifying 1522 state blocks can be accomplished by executing 1522 an application program across its normal operating range, and keeping track 1522 of which storage operations have been written, how often, and in what order. Neutral net worth, statistical analysis, or other similar techniques and tools can be used to extract 1522 a status block identification result from the obtained log file. Log files accumulated over time should show that some storage units are accessed/written more frequently than others, and should therefore be considered 1522 status blocks. If no such obvious statistically relevant patterns are found, then this law does not apply to the applications discussed here. The method of the present invention does not necessarily work with every storage utilization application.

When this method is properly adopted, if the application fails and cannot be restored, it can be updated by the data block continued by the undelivered 1524 and the status block written between the undelivered 1524 and each status block update operation to assist in recovery until the application is able to recover its state. To support this uncommitted functionality, the present invention stores data units that are overwritten between state block update operations in a form of non-volatile storage. Alternatively, the present invention may buffer before delivering store operations back to disk, and free up the desired buffer space after the next set of state block store operations are detected and processed. Read operations should be read from buffered storage, not from the delivered copy. A table can be maintained showing the location of a given data unit in a buffer or on delivered storage.

Resynchronization from a first data volume to an unauthorized second data volume

The present invention may also provide tools and techniques for resynchronizing an unauthorized second data volume, such as a remotely replicated disc subsystem 312 or 614, from a first data volume such as locally replicated 210 to facilitate utilization The second data capacity is capable of disaster recovery after a period of time as the first one.

Under normal operation, data units are written into a first data volume and then written into a second data volume by some means, such as replicating units 204, 208. The data on the first data volume is considered authorized, and therefore is queried when a data unit needs to be accessed. In the event of a non-destructive failure of the first data capacity (i.e., such as a power failure or temporary isolation of a consuming application from an existing data unit), the consuming application will switch to the second data capacity to store a new data unit and read data unit. Here, a list (eg, window, or other data structure) is maintained 1526 indicating the data units that will be changed on the second data volume when the first data volume is not available. The list is queried when the first data volume becomes available to resynchronize 1526 the contents of the second data volume with the contents of the first volume. The resynchronization 1526 process reads the corresponding data unit from the first volume and writes it into the second data volume.

In this scenario, changes to the second data volume are assumed to be unauthorized and are normally overwritten by the resync 1526 . And this may be on the grounds that it is specific to the exploiting application, for example.

Thus, under appropriate circumstances, the present invention can provide a simple method for re-establishing the first-second relationship between two data volumes. This resynchronization 1526 differs from role swapping 1506; in a role swapping, the second capacity becomes the first authorized capacity, while in resynchronization 1526, the first authorizing capacity remains authorized.

Maintain an ordered queue and a current copy on the same physical storage system

That is to say, as described herein, in some embodiments, the replication unit 204 stores the written data units in an ordered queue in the order in which they are received, so that they can be read back sequentially. In some embodiments, a group of data storage units is defined as a "current copy", and these data storage units are read back 1528 from the current copy as a whole. A new store operation on a given data unit of the storage device updates 1528 the data units within the current copy, while each data unit is still available 1528 to be read to restore the previous system state.

This is managed by a window (or other data structure) that maintains 1528 a copy of the location of the currently replicated storage unit. This window identifies the address of the most recent data unit for a given storage unit in the current replication. When the request is processed, the data unit is checked 1528 in the form and read from the ordered queue when the form is referenced. Here, each ordered read request 1528 is processed by reading from a known position in the ordered queue in a queue-forward manner.

Accordingly, there is no compelling reason to keep two copies of the same data unit as physical divisions. The present invention can avoid writing the same data unit twice in the storage system to implement a physical partition system. Note that in different embodiments of step 1528 , one or more specific operations collectively labeled as section number 1528 may indeed be included or omitted.

When the physical storage system is full of ordered queue data, the oldest ordered queue unit will be timed out by 1528, and those storage spaces will be released for use by new ordered queue units. If an old ordered queue unit in the current set needs to be timed out, it can be copied 1528 to a second storage device and the ordered set 1528 updated to point to this new location. Whether this is a common scenario is application specific, but in many cases this feature of the present invention 1528 will tend to reduce the writes required both for maintaining the current collection and for an ordered queue view of a set of data units number of operations.

As a result of maintaining an ordered queue, the previous current set is available for reconstruction 1528 . Here, by selecting 1528 an ordered queue as a new current set at a point in time, scanning 1528 the reference frame to refer to each unit of the ordered queue that is newer at the selected time point, and then The reference window is updated 1528 to refer to older SQUs, and these would refer to the correct part of the current set, thereby recreating a previous current set.

In many cases, this embodiment of the invention 1528 pays a performance penalty for read operations because in some cases, this does not occur on sequential storage units. However, the storage operation should be effective in any order, because the storage operation is preferably always on the consecutive storage units arranged in an ordered queue, that is, if the ordered queue is implemented as a spanning one A linear array of memory cells in the storage system.

Configure storage media and signals

Objects made within the scope of the present invention include a computer-readable storage medium incorporating a physical configuration specific to a substrate of the computer-readable storage medium. The substrate configuration represents data and instructions that allow the computer to operate in a specific and predetermined manner as described below. Suitable storage devices include floppy disks, hard disks, magnetic tape, CD-ROMs, RAM, flash memory, and other media that can be read by one or more computers. Each of the aforementioned media can implement programs, functions and/or instructions that can be executed by a machine, so as to perform the steps of the flexible copy method discussed here, including but not limited to the execution of the parts or instructions shown in Figure 13 are all the steps and methods for installing and/or using the systems shown in Figures 2 to 12. The invention may also provide novel signals used or employed by the program. These signals can be implemented by "wire", RAM, disk or other storage medium or data carrier.

extra information

To further assist individuals and businesses in understanding and properly making the present invention, additional relevant information and details are provided. These discussions are based on subsequent assumptions, and unless otherwise stated, any discussion of an embodiment type (method, system, or configuration storage medium) is also applicable to other embodiments.

Improved Specific Embodiments of the Invention

Many other solutions to data protection problems (tape backups, regional clustering, replication, shadow replication, remote mainframe channel expansion, etc.) all require more or less direct connection to the host 200 operating system and are associated with it. This correlation can cause confusion for customers and can be avoided using this method. For example, assuming that the software cannot fully operate under the current host operating system or an upgraded version of the operating system, then relying on related proprietary software may cause compatibility problems and errors. Software solutions that rely on dedicated host replication software can also create performance issues because they place extra work on the host. Associated software solutions can also cause instability issues. When the disk directory increases and the software and operating system become more complex, these problems need more related software to solve. Furthermore, if the operating system of the host 200 is down, solutions that rely on the operating system will not work.

In contrast, at least in some embodiments, the present invention does not use software that would increase the load on the host computer (ie, the local server 200 ), thereby reducing or avoiding the above-mentioned problems. If the host operating system goes down, the replication unit can continue to operate and the replicated material can still be used because the replication unit executes its own operating system. Unlike solutions that have to be substantially modified at the core, the present invention scales instantly as the disk catalog grows and the software becomes complex. If the disk space is large, the larger disk can be placed in the replication unit. If the rate of data change exceeds the current ability to write to disk, use a cache controller and increase the system's memory. Certain other solutions require the cooperation of other operating system vendors in order to integrate smoothly and operate without error. Since all operating systems support (say) SCSI and Fiber Channel for the foreseeable future, installation and use of the present invention does not require such cooperation.

When other solutions fail, the host 200 can be used because of the close interaction as described above. Since the operation of the system is not related to the host computer 200, the host computer will not be seriously affected if a fault occurs. Traditional disk replication was originally designed to provide regional fault tolerance. Write to two disks in parallel, and if one disk fails, the computer can still function. A failed disk can be unmounted by the operating system in background mode. The operating system and computer continue to operate without any failure. Similar advantages are provided because the replica unit of the present invention can be viewed as a SCSI disk and mounted as a replica disk. If the replication unit crashes, simply uninstall it. For example, if the operating system or other software on the replicating unit fails, the replicating unit may stop emulating operation as a disk drive. Therefore, the operating system of the host 200 no longer recognizes the replication unit. In this regard, the operating system of the host 200 only needs to uninstall the replication unit 204 and continue to operate.

At least some of the previously described replication system embodiments use a single disk IDE buffer. Even with spoofed packets, this smart buffer can't keep up with high-speed SCSI RAID units with hardware stripping. The most important data previously sent to the remote location is stored on a single disk without fault tolerance in terms of intelligent buffering. In contrast, using the present invention, the local and remote replication units can simultaneously replicate a single disk buffer with fault tolerance, and can perform hardware RAID stripping on multiple disks. This provides both the ability to keep up with the server-side high-speed storage subsystem and better fault tolerance. This can also reduce the risk of missing buffer data in case of an accident in the disk directory of the server 200 or a certain disk of the replication unit disks 210 , 310 .

The data input capacity limitations of previous methods make it very difficult to propose new technologies that can be accepted by the market. For example, at least in some of the previously described approaches, there is no support for "storage access network (SAN)" or network-attached storage (NAS). The requirement for standard remote servers like server 300 makes it extremely difficult or impossible to provide backup and replication for increasingly popular SAN and NAS disk subsystems. However, all of these subsystems can perform local copy operations over Ethernet, Fiber Channel and/or SCSI. The new duplication unit accepts a variety of input types, including SCSI, Ethernet and Fiber Channel inputs.

The invention also provides support for larger storage subsystems. Many earlier fault-tolerant solutions were designed for use in environments where even 6Gigabyte storage disk capacities are considered large. Disk subsystem capacity is rapidly increasing due to lower storage costs. Even server disk capacities of 100Gigabytes are not uncommon these days. The present invention accommodates these larger disk directories, in part by performing host server 200 synchronization in, for example, replicated unit background mode. Offloading the workload from the host server to the replication unit allows the central host server 200 to be fully replicated without significantly degrading performance. Conversely, additional "clustering" and/or replication schemes that require a local server to handle the synchronization required for replication can degrade or even destroy the primary server's performance.

Although the specific embodiments try to avoid re-synchronization operations (re-replication) on the replicated disk via the communication link, at least some of the foregoing re-replicated embodiments require the local server to 200 to intervene. The re-replication operation would slow down the central/primary/master server 200 to a standstill, and possibly for several days. Therefore, the re-copy operation is generally performed on weekends when there are fewer users and the network can be slower. But when the disk subsystem gets bigger, this becomes unacceptable. The present invention can support non-volatile storage not only remotely but also locally in the replication unit 204, which can hold the entire disk directory to be replicated to the remote location. This may allow the local copy unit 204 to pre-commit to a local smart buffer for the full local disk capacity and perform re-copy operations in the context of the server 200 point of view.

In at least some of the aforementioned approaches, the maximum output limitation of the T1 output, whether local or remote, slows down recopy operations even if frame relay, ATM and/or VSAT networks are available. On the contrary, the present invention can flexibly provide larger I/O pipeline capacity to improve performance, because re-copy operations can be made faster and data placement can be more efficient. If the replicated data stored remotely is unavailable, the data placed in the unavailable location can be transferred to another facility at high speed via a high-speed private data network. These data networks generally support bandwidths up to OC48 (ie 2.488 Giga bytes per second). One example is a customer who normally copies data to Chicago, but now needs to use facilities in New York for restore operations. This type of demand is more frequent than originally thought.

Previous Off-SiteServer products could not provide an open "application programming interface (API)". Instead, it is completely closed dedicated hardware (MiraLink) and closed dedicated software (Vinca). If an enterprise customer has needs outside the scope of the product, there is generally no easy way to make custom modifications or adjustments. In contrast, the present invention can provide an open API so that these modifications can be made by client programs for specific customers or emerging markets. In particular, but not limited to, the present invention has an API that can provide one or more calls to configure settings for the replication unit without interrupting the server 200, and also provides a call to restart The replication unit is activated without interrupting the server 200 .

configuration data

The system configuration data is preferably stored in a decentralized manner, so that in case the replication unit loses the configuration data, the configuration data can still be recovered from each unit point. For example, the basic configuration data such as network information is preferably stored in a non-volatile storage device (that is, on a magnetic disk, or a semiconductor memory with a dry battery), so that even if the configuration data on the disk is lost, the configuration data can still be used by the replication unit The relative point is restored.

The World Wide Web interface preferably provides at least the following configuration options or their equivalents: IP address (remote/local), netmask (remote/local), administrator password (shared), buffer size (local), Buffer high water mark (buffer is full beyond an acceptable level), disk capacity size (configurable to a maximum value set by the manufacturer), SCSI target "logical unit number (LUN)", SNMP configuration settings set (remote/local).

The SNMP configuration settings themselves should preferably include the following items: add/remove SNMP replication hosts (remote/local), event polling interval, buffer full beyond acceptable limits, network connection down, buffer full, remote Out of sync, adding/removing email recipients.

The web interface should at least provide the following status information: the number of data blocks in the buffer, the number of data blocks that have been sent, the number of data blocks that have been received, the version of the copy unit, the serial number of the copy unit, the size of the disk directory, and whether the unit is remote or locally. The web interface preferably provides an unmounted remote utility. Preferably, the web interface also provides a log dump report. SNMP and SMTP traps are typically used for the following events: buffer full beyond acceptable limits, buffer full, network connection down, remote has lost synchronization.

The management tool may provide notification operations by e-mail, pager, or other methods. Notification operations may be real-time and/or incorporated with automated logs or automatically generated reports. The notification operation can also be sent to the system administrator and/or the vendor. In embodiments that interface with an executing web server/email package, many of the features of web pages can also be utilized. For example, the user can access and manage the replication unit locally or remotely. Depending on the individual rights, the user can access the reproduction unit internally within the company and/or from any location in the world. The replication unit can notify users (and the replication unit vendor) of problems and major events in the replication unit through email and SNMP. It is also possible to compose a dedicated and customized document program document for the e-mail, so as to notify different users or groups of users. Report output is not a required item. If the customer requires special reports for management purposes, rather than duplicating the required data every month and rewriting the data over and over again, the customer or the notified designer can use HTML, JAVA and/or other familiar tools and techniques to Let the replication unit generate and email the report in the desired format.

basic hardware

In general, a system consistent with the present invention should include basic hardware such as a standard Pentium II, Pentium III, AMD K6-3 or AMD K7 class PC compatible computer (with the respective manufacturer's brand). In various configurations, the device preferably has at least 64, 128 or 256 Megabytes of RAM, and a mounted computer case. It is also best to include a 100Mb Ethernet network card, FDDI adapter card, and so on. As for the disk drive interface, the device preferably has a Qlogic SCSI adapter card for disk drive emulation, an Adaptec 2940UW adapter card for buffering and copy control, or a DPT brand RAID adapter card supported by FreeBSD. Cache can also be used, including RAID or SCSI controller cache, volatile memory RAM cache for replicated units, non-volatile memory RAM cache for replicated units (ie, static RAM or battery attached RAM), and the like. Those who are familiar with the tools and techniques of caching can immediately modify the application according to the present invention.

In some embodiments, if N is the size of the disk directory to be copied, then the local copy unit 204 including the local copy file 230 must have at least N storage capacity to be used as the local copy file. In some embodiments, the disk system used to serve the local buffer 210 (whether it has a local copy file or not) needs to have a capacity of at least 6/5 times N, that is, 1.2 times N. The remote replication unit has at least one disk system with a capacity of at least N for providing remote replication files. In all cases, the local replication unit buffer 210 will probably require the same data capacity as the remote replication unit, including the buffer and hot-swap RAID subsystem, to provide local re-replication.

Package test items

The measurement items used to measure the performance of the system according to the present invention preferably include analytical tests to measure relative performance, and Boolean (pass/fail) tests to cover key functional specification compliance criteria. The Boolean test is passed if the specified answers to all questions correctly match the test results. This Boolean test can be used to determine the suitability of the transfer.

Testing is preferably performed in a local network configuration (where the journey link 206 is within a single local area network), and in a local and remote configuration (where the local replica unit 204 and the remote replica unit are geographically separated from each other). For example, a remote network configuration may include two locations connected by T1 link 206 , or public Internet bandwidth equivalent to tour link 206 .

Analytical testing is best done with a standard disk hardware suite such as Bonie (for UNIX), or PCTools (for Windows NT and Novell users). This test allows for a performance comparison between the original disk drive (noting its type, size and characteristics) and the elastic replication unit 204 . Record its output performance for future reference.

It would be a good idea to ask the following questions and make necessary corrections until the answers listed are met.

Does the host 200 operating system recognize the replication unit 204 as a disk drive of the correct size? (Yes)

Can data be read and written to the replication unit 204 without loss? (Yes)

Can the host system 200 perform any file operations on the data on the replication unit 204 for 48 hours without loss? (Yes)

Can the local copy unit 204 installed with a 100 Mega byte host disk directory and a remote network configuration successfully copy data to the remote copy unit at 300 Mega bytes per hour, or higher if FDDI and others are supported ? (Yes) Note that the 300 Megabytes per hour rate is less than 50% of the maximum capacity of the T1 connection; the T1 capacity is about 617 Megabytes per hour.

Can the local replicating unit 204 be rebooted without causing the attached host system 200 to fail to operate normally at all, in other words, the host 200 can continue to perform the intended purpose without significant performance degradation? (Yes)

When the local replication unit 204 goes online again, can it automatically start transmitting the data left in the queue of the local replication unit 204 through the network or other journey links 206 (i.e. using the TCP socket protocol), and send the data to the remote replication unit , without data loss? (Yes) Note that this should be done when the local mirroring unit 204 is attached to the host system 200, before and after the local mirroring unit 204 is rebooted, and the remote mirroring unit disk drive is mounted on the host system 200 way to confirm. After this event, remote clones should still be mountable without significant need for filesystem repair. Data should not be lost and should be justified by the application that generated it. After the replication unit entity is mounted to the local host system 200, can the host system 200 mount the replicated file, and can the application program and its client on the host system 200 successfully use the data of the replicated file? (Yes)

Will the replication system crash or crash for incorrect information entered eg wrong remote IP address, or invalid SCSI ID (less than zero or greater than 15)? (No) Can the user correct the information, restart the software and let it run normally without reactivating the replication unit? (Yes) Do all software display the correct version number and copyright notice? (Yes)

Can the local replication unit 204 continue to operate if the network cable 206 is disconnected for about 30 minutes or more while the host system 200 is performing replication operations or other disk I/O? (Yes) and will it be recognized by the host operating system as a disk drive with the correct set capacity? (Yes) Is it possible to read and write data to the local replication unit 204 without data loss? (Yes)

After the initial replication operation was established, the network cable was disconnected for about 24 hours, and then a periodic retest operation was performed. Will the local copy unit 204 still be recognized by the host operating system as a disk drive with the correct capacity? (Yes) Is it still possible to read and write data to the local replication unit 204 without data loss? (Yes)

Likewise, after forcing the buffer 210 of the host system 200 to overflow (ie, replicate multiple times), it is confirmed that the local replication unit 204 is still functioning as well as possible. Will the local copy unit 204 still be recognized by the host operating system as a disk drive with the correct capacity? (Yes) Is it still possible to read and write data to the local replication unit 204 without data loss? (Yes) Can a user stop and restart the enqueuing of a program without requiring the local replication unit 204 to reactivate? (Yes) Can the user stop and restart the dequeuing of the program without requiring the local replication unit 204 to reactivate? (Yes) If at least some of the data has been copied more than once, can the user selectively flush specific buffer sections, i.e. flush the aborted copy operation, without flushing the entire copy operation? (Yes)

When the host system 200 is performing a copy operation or other disk I/O intensive operation, the network cable or other journey link 206 is disconnected for about 30 minutes. After the physical network link is established, can the local replication unit 204 still start sending data to the remote replication unit through the queue? (Yes) Valid statistics from the local replication unit 204 to buffer status (i.e. overflow or not, number of data blocks in the buffer, number of data blocks sent from the buffer and received by the remote) Is it still available? (Yes)

Unplug the UPS from the local replica unit 204, shut down the local replica unit 204, and wait for the local replica unit 204 to be powered off. First reconnect the local replication unit 204 to the power supply, and then reconnect the host system 200 to the power supply. Does the host system work normally? (Yes) Can the local replica unit 204 be fully reactivated without rendering the attached host system 200 inoperable? (Yes) When the local replica unit 204 comes back online, can it automatically start transmitting the data left in the local replica unit buffer 210 through the network or other journey link 206 without data loss? (Yes) Note that the last two of these remote copy mount tests should be performed both before and after this power failure simulation. Is it passable? (Yes)

In addition, if the capacity of the host disk directory is 200Giga bytes, can the aforementioned tests pass? (Yes)

Can the remote replication unit be turned off, and can the remote replication file be mounted by another standby server running the same operating system as the first host system 200? (Yes)

Can the remote host then operate normally without impacting its performance? (Yes) Note that the preceding two test operations are supported by a remote backup host attached to the same SCSI chain as the remote copy unit and its remote copy disk subsystem 312 or 614 .

epilogue

The present invention can provide local and/or remote data replication tools and techniques. In particular, a remote data replication computer system according to the present invention includes one or more flexible replication features. Local replication systems (ie, where the source and destination are less than 10 miles away) can also have this elastic replication feature.

For example, the system may have a serverless terminal setup, i.e. an embodiment of the system goes from a local server 200 as a source to a remote replication unit 208, 408, 508, 608 or 708 as a terminal via a local replication unit 204 without requiring Used on remote servers housed in remote replication units.

For example, the system can also be configured as non-volatile, so that no software designed for remote data replication needs to be installed on the local server 200 . Also, there is no need to install such software on the second server 300 included in the system containing the second server 300 . Instead, each replication unit executes its operating system and one or more remote data replication applications (including executors, programs, tasks, etc.). For example, it is the replication unit rather than the server that buffers the data to be replicated, makes and monitors connections to the journey link 206, and transmits/receives replicated data on the journey link 206, and then decommissions the server. Similarly, the system also has the feature of disk emulation, so that the system replicates data from the local server 200 to the local replication unit 204 through a standard storage subsystem bus. Suitable standard storage subsystem buses include SCSI, Fiber Channel, USB, and other non-proprietary buses. These buses are also considered herein as "connections" to the local replication unit 204 .

The system also features TCP journey links 206 and/or Ethernet journey lines. For example, the system uses the local server 200 to replicate data through the local replication unit 204 as the TCP client of the journey link 206; the remote replication unit 208, 308, 408, 508, 608 or 708 as the TCP server. Generally speaking, the characteristic value of the journey line represents the requirement of high bandwidth and low delay of SCSI, and the original Off-SiteServer serial connection, SAN connection, etc. do not appear on the connection 206 between the local replication unit 204 and the remote replication unit.

The system can also be viewed as having multiplicity features. In other words, the system can provide many-to-one replication operations from two or more local (primary) servers 200 to a single remote replication unit 208 , 308 , 408 , 508 , 608 or 708 . Then, the data replication system of the non-volatile storage device of the remote replication unit can include a disk sector for each main network server 200, and each disk sector holds the replication data of each relative server 200 for each An external hard disk 614 for the server 200, a RAID unit 312 for each server 200, or a combination thereof. The various primary (local) servers 200 may use the same operating system, or a combination of different operating systems. In some cases, the target non-volatile storage device capacity is sufficient to store the existing consolidated non-volatile data of all primary servers 200 . As for another multiplicity feature, the system can provide one-to-many replication operation from a given local (primary) server 200 to two or more remote replication units 208, 308, 408, 508, 608 or 708 .

The system can also provide a variety of methods including installing the elastic replication unit, using the unit, and both. For example, a method for providing elastic data replication includes at least two steps implemented by group 1300 . Another method for elastic data replication includes one or more transmission steps 1302 .

One of the installation steps involves connecting from local server 200 to local mirroring unit 204 with a standard disk subsystem bus 202 , thereby allowing local mirroring unit 204 to emulate a disk subsystem to communicate over link 202 . Step 1306 involves connecting the local replication unit 204 to the journey link 206 for data transmission by at least one Ethernet connection and a TCP connection. Step 1308 involves connecting the remote replication unit 208, 308, 408, 508, 608 or 708 to the journey link 206 for data reception via at least one Ethernet connection and TCP connection. And when at least some part of one of the aforementioned connecting steps is completed, the testing step 1310 is to test at least one of the remote mirroring units 208 , 308 , 408 , 508 , 608 or 708 .

One of the transmission steps 1302 is step 1312, which transfers data from the local server 200 to the local replication unit 204 through the standard disk subsystem bus 202 when the local replication unit 204 emulates a disk subsystem. Step 1314 transmits the data from the local replication unit 204 to the remote replication unit 208 , 308 , 408 , 508 , 608 or 708 through the journey link 206 . And when the remote replication unit belongs to serverless, in other words, if it is not attached to the second server 300, step 1316 (which can also be performed as the data transfer in step 1314) is to transfer the data from the local replication unit 204 through the journey link 206 and transmitted to the remote replication unit 208, 308, 408, 508, 608 or 708 place.

In these and other embodiments, the present invention may have additional features, such as those directed to role swapping 1506; hot standby server implementation 1508; various buffering and other storage features 1510, 1518, 1528; Instruction Capture 1512 and Replay 1514 on the Internet; Transaction 1516; Executing Multiple Remote Copy Unit Software Embodiments 1520 on a Single Hardware Platform; Based on Observations Over Time, Rather Than Detailed Updates on Storage Operations for a Given Application Frequent access data identification processing 1522 for advanced knowledge, to support application state restoration 1524;

Embodiments of the present invention can mask the delay of the journey link 206 even on relatively low-bandwidth connections to the remote replication unit, thereby enabling replication where previously even dedicated fiber was not available. In this case, it helps to obtain long-distance off-site (off-site) replication, and helps to perform replication operations on low-cost network connections. Even if this low-cost connection only has enough bandwidth to support the average platter data exchange speed, but not the bandwidth to support the peak speed, it can be used without error. The specific embodiments of the present invention are not only suitable for backup and recovery, but also can be used as a high-availability first storage system. In remote many-to-one embodiments, the core module, or a software interface to the buffer i.e. SCSI or other transport protocol, can be replaced with a more generalized user space control module to emulate the system interface without the need for real SCSI or other transport protocol processing layers. These devices may include, for example, local buffers, remote buffers, local replication, remote replication, and SCSI or other transport protocol layers. The hardware platform executing the SAN management software can be in a centralized manner.

Specific embodiments (methods, storage media for configuration settings, and systems) of the present invention are illustrated and described hereafter. In order to avoid unnecessary repetition, the concepts and details applicable to one specific embodiment will not be separately described in other specific embodiments. However, descriptions herein of particular embodiments of the invention are applicable to other embodiments unless otherwise indicated. For example, the discussion of the system of the present invention is also suitable for its method, and vice versa; and the description of the innovative method is also suitable for the corresponding configuration setting storage medium, and vice versa.

As used herein, "a" and "the", as well as specified items such as "a unit of reproduction", generally include one or more of the specified items. The present invention may also be embodied in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects as illustrative only and not restrictive. Headings are for ease of understanding only. The scope of the invention is therefore indicated by the appended claims rather than by the foregoing description. All changes in context and scope of language are included within its scope.

Claims (13)

1. A method for elastically duplicating remote data, comprising the steps of: Steps for replicating material between local and remote replication units; Execute the steps of the local-remote role exchange operation of each replication unit; the step of setting a second server in hot standby mode; the step of storing changing logical block numbers in a ring buffer instead of changing data in the ring buffer; the steps of probing a bus and buffering at least one command obtained by the probing step; The steps of utilizing a core insert to provide transaction file system functionality; The steps of performing a read/write/write copy operation are to read a data block from a local copy unit, write the data block into a temporary storage device as a new block, and update a logical block number item in a queue , write the new block into a set of replicated data, and append a new block logical block number entry to the queue; the step of reading data and providing a virtual remote copy unit; the step of reading data and identifying frequently accessed data units without prior application-specific knowledge about the sequence and frequency of an application's storage operations; the steps of reading data and resynchronizing an unauthorized second data volume from a first data volume after replacing the first data volume with the second data volume; The process of reading data and maintaining an ordered queue of copied data units and a current copy of a copied data unit on the same physical storage system, thereby eliminating the need to write the same data unit to the storage system twice to implement An entity segmentation system. 2. The duplication method according to claim 1, wherein the step of storing the changed logical block number further comprises: when a block corresponding to the logical block number is overwritten, in the buffer the step of changing a logical block number in situ to refer to data at a second location rather than to data at a first location that holds data for the block before the block was overwritten , and the second location stores the data of the block after the block is overwritten. 3. The duplication method according to claim 1, wherein said step of setting a second server in hot standby mode comprises the following steps: booting to activate the second server, and then from an existing remote duplication unit , providing a "media not standby" signal to the second server, whereby the emulation layer of the replication unit responds to requests from the second server for size and availability, but rejects the second server's access to data content until the role of the replication unit has changed. 4. The replication method of claim 1, wherein the step of probing a bus and buffering at least one command obtained by the probing step further comprises a step of separating read-type commands from write-type commands It can be seen that the read-type commands are from a read-type probe bus master controller request, and the write-type commands are from a write-type probe bus master controller request, and wherein the The buffer step buffers write-nature instructions. 5. The replication method of claim 1, wherein the step of probing a bus and buffering at least one command obtained by the probing step further comprises passing the buffered command from a local replication unit across a communication link The step of transferring to a remote replication unit. 6. The replication method of claim 1, wherein the step of probing a bus and buffering at least one command obtained by the probing step further comprises a step of replaying a command from a remote replication unit, the command being a buffered by the local replication unit. 7. A remote data elastic replication system, characterized in that: the system includes: At least two replication units; the replication unit includes a buffer, and a storage device that stores changed logical block numbers in the buffer instead of storing changed data in the buffer; the replication unit also includes a data storage media and an emulation layer, the emulation layer has a response from the second server by providing the characteristics of the data stored in the storage medium and by rejecting the second server's request to access the content of the data the requested device; means configured within the system to perform a local-remote role-swap operation of a replication unit; a SCSI bus, and at least one device for copying data, probing the SCSI bus, and buffering at least one SCSI command obtained by probing; A core insert to provide transactional file system functionality during the data replication process; A read/write/write copy execution device for copying and reading a data block from a local, writing the data block as a new block to a temporary storage device, and updating a logical block number in a data structure entry, writes the new block into a set of replicated data, and appends a new block logical block number entry to the data structure; a means for identifying frequently accessed data units without the application of specific knowledge; means for resynchronizing an unauthorized second data volume from a first data volume after replacing the first data volume with the second data volume; An ordered queue of replicated data units and a currently replicated device of the replicated data units are maintained on the same physical storage system. 8. The replication system of claim 7, wherein the storage device comprises a virtual block configuration structure. 9. The replication system of claim 8, wherein the virtual block configuration structure includes block checksums instead of block data. 10. The replication system of claim 9, wherein the replication system transfers block checksums across a journey link to another replication unit during resynchronization of two replication units, rather than across The journey link transmits block data. 11. The replication system as claimed in claim 7, comprising a local system and a remote system, wherein the remote system comprises a device which can receive data change information from the local system and keep a buffered Log files of data changes on the remote system, and support for changing role swaps at the request of an administrator. 12. The replication system of claim 7, comprising at least two virtual remote replication units on a single hardware platform. 13. The replication system of claim 7, wherein the means for identifying frequently accessed data units without application of specific knowledge can be performed by undelivering continuation between state block update operations The data block and the undelivered state block are updated until the application state is indeed restored to coordinate means for assisting in restoring the application state.

Images