KR20030066331A - Flexible remote data mirroring - Google Patents

Abstract

A method, system, and storage medium for forming the same are provided for flexible data mirroring. More specifically, the present invention relates to a local-remote role shift 1506, meeting a hot standby server state via a "media not ready" signal (1508), various alternative buffer contents and buffering schemes, transactions (1516), Many-to-one mirroring 1520 through the use of "virtual" remote mirroring units, identification of frequently accessed data 1522 based on log and analysis of applications instead of specific application knowledge, and use of unauthorized secondary servers Provide (1526).

Description

Flexible remote data mirroring {FLEXIBLE REMOTE DATA MIRRORING}

U. S. Patent 5,537, 533 discloses tools and techniques for remote mirroring of digital data from a primary network server to a remote network server. The system according to this patent comprises a primary data transmission unit having a primary server interface and a primary link interface, and a remote data transmission unit having a remote link interface and a remote server interface. The primary link interface includes a spoof packet generator that can generate pre-acknowledgement for the primary network server. That is, the system may notify the primary server in advance, i.e., after the mirrored data is stored in the non-volatile buffer of the primary link interface, and before a notification indicating that the mirrored data has been stored by the remote server is reached. It has a "smart buffer" that provides a "spoof".

Miralink Corporation of Salt Lake City, Utah is a patent owner of US Patent No. 5,537,533. Miralink manufactured off-site server products commercially available (OFF-SITESEVER is a trademark of Miralink) prior to one year prior to the filing date of the invention. Off-site server products include technology for remote mirroring Novell Netware (NETWARE is a trademark of Novell, Inc.) to other servers in geographically remote locations over low bandwidth remote communication links. .

Remote mirroring of data from the primary network server to a remote alternate network server using data mirroring is a powerful and efficient way to back up data. Remote mirroring creates a copy of the data at a safe distance from the original data substantially simultaneously with the storage of the original data. If the remotely stored data has been copied to a "warm" remote network server, i.e. a remote server that can start up and operate as a new primary server within minutes of actual or simulated disasters, this data can Even immediately available.

In a typical installation, off-site server products use a pair of site server boxes, including local boxes and remote boxes. The off-site server box is generally configured as certain hardware, firmware, and / or other software, as disclosed in US Pat. No. 5,537,533. A dedicated serial line connects the local network server to one of these boxes. The NetWare server itself uses a Vinca card (VINCA is a trademark of Vinca Corporation). The card intercepts disk-driver requests and sends the data down the serial line to a local off-site server box.

The local off-site server box has a 4GB nonvolatile buffer like the IDE disk drive. Data is notified in advance to the off-site server buffer. As long as the operating system of the local server is involved, a second "mirror" write occurs locally. In practice, off-site server products receive data from the NLM and store it in local buffers. The local off-site server box stores sector and track (or block level) data changes until the remote off-site server box is securely transferred. In addition, the buffer in the local off-site server box is "smart" in that it stores any of the above data that the remote communication link can handle locally. This data is stored in the local off-site server box until the remote off-site server box is successfully written to the remote secondary server and resends the notification to the local (primary) off-site server box. When the notification is received, the local off-site server box frees up the local non-volatile buffer occupied by the successful transmission portion of the sector / track / block data.

Off-site server products use the V.35 interface for data output at the local (primary) site. V.35 is a set of remote communication standards that connect to a channel service unit / data service unit (“CSU / DSU”), which interface with the remote communication link. The remote (secondary) location has a second CSU / DSU that relays sector / track / block information to the V.35 input interface of the remote secondary off-site server box. The secondary off-site server box outputs sector / track / block data via a dedicated serial connection using a serial cable connected to the remote bincar card of the secondary (remote) server. The data mirroring and system software of the remote server then writes sector / track / block information to the disk drive of the remote server, which is notified back to the local off-site server box. The system can handle about 300MB of change data in less than an hour.

Off-site server products are intelligent enough to detect whether there is a reduction or increase in bandwidth and / or whether the remote communication link is down. During link downtime, the off-site server box stores data changes from the server in a local nonvolatile smart buffer. When the link is reactivated, the off-site server product automatically starts transmitting. Off-site server products may change their bandwidth output as more or less bandwidth is available. In addition, all of the transmissions described above include standard software checksum error detection and correction, and / or hardware error correcting code (ECC) error processing.

In the case of a disk or server failure on a local (primary) network server, the secondary (remote) server connected to the remote (secondary) off-site server box in the same manner as just described is the local (primary) server. Have a fully mirrored disk copy of all data on the disk. This remote backup copy can be restored to the local (primary) server. In addition, the secondary remote server can replace the local primary server in the event of a disaster. Such secondary resave and / or replacement can be performed relatively quickly using a simple set of command lines.

In summary, off-site server products and other remote data mirroring technologies provide valuable fault tolerance and disaster recovery capabilities for both mission-critical data and other contexts. Nevertheless, these existing methods have unnecessarily limited flexibility.

For example, off-site server products require specific versions of hardware and software from Vinca. This required version of Bingka does not support any operating system / file system platform other than the Novell NetWare platform. Also, the hardware components of the required binka packages do not work with newer, higher speed servers and larger disk volumes.

In addition, the original off-site server product is designed such that one local server connects to one remote server. Only a single server can mirror to a remote server at any given time. Multiple servers at different locations cannot be easily mirrored to a single remote site. Similarly, if an enterprise has multiple local servers running different operating systems and / or file systems, each server running each platform should be mirrored to a matching remote server.

In addition, the original off-site server product requires NLM on the local server and is designed to use a dedicated remote communication link. In addition, conventional mirroring requires a remote server to maintain the mirrored information in a remotely bootable format.

The differences from the above limitations are pointed out in US patent application Ser. No. 09 / 438,184, which is a parent application. The present invention provides additional tools and techniques for remote data mirroring to obtain advantages and other advantages over the techniques discussed in this application.

The present invention relates to remote mirroring of digital data from a server or other computer to provide more desirable fault tolerance and / or disaster recovery, in particular the flexibility of remote data mirroring. A tool and technique for increasing flexibility.

1 illustrates conventional mirroring in a computer network that may be applied for use with the present invention.

2 shows a computer system according to the invention comprising a remote mirroring unit with a larger buffer, without a remote server.

3 shows a computer system according to the invention comprising a remote server with a remote mirroring unit having a relatively small buffer and a hot-swappable RAID unit.

4 illustrates a computer system in accordance with the present invention including a remote swapping unit having a hot swappable RAID unit and a relatively small buffer, without a remote server.

5 illustrates a single remote mirroring unit having several hot swappable RAID units and a relatively small buffer and several local servers operating a given platform with each local mirroring unit, without a remote server. Diagram illustrating a computer system of many-to-one mirroring.

FIG. 6 illustrates a single remote mirroring unit having several separate external storage volumes and a relatively small buffer, and several local servers operating a given platform with each local mirroring unit, without a remote server. Showing another many-to-one computer system according to the drawings.

FIG. 7 shows a single remote mirroring unit and each local mirroring unit having a hot swappable RAID unit similar to having several partitions, an external storage volume having multiple partitions, and a relatively small buffer, without a remote server; Diagram showing another many-to-one computer system in accordance with the present invention comprising several local servers operating a given platform.

8 illustrates a single remote mirroring unit having a hot swappable RAID unit and a relatively small buffer and several local servers operating different platforms with each local mirroring unit, without a remote server. A diagram illustrating another many-to-one computer system.

9 shows a single remote mirroring unit having several external storage volumes and a relatively small buffer and several local servers operating different platforms with each local mirroring unit, without a remote server. A diagram illustrating another many-to-one computer system.

FIG. 10 shows a single remote mirroring unit and each local mirroring unit having a hot swappable RAID unit, an external storage volume having multiple partitions, and a relatively small buffer, similar to having several partitions, without a remote server. Diagram showing another many-to-one computer system according to the present invention comprising several local servers operating different platforms.

11 shows a one-to-many mirroring computer system according to the present invention in which a local server is connected to several local mirroring units for data mirroring to several remotes.

12 shows an alternative example of a one-to-many mirroring computer system according to the invention in which a local server is connected to one multi-ported local mirroring unit for data mirroring to several remotes.

13 is a flow chart illustrating the method of the present invention.

Figure 14 illustrates a dual host configuration between a remote mirroring unit, a remote server, and a RAID unit that can be used to perform a switchover in accordance with the present invention.

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

The present invention provides mirroring tools and techniques that can be used in combination with other inventions or in other embodiments. US non-provisional patent application 09 / 438,184 is included in the present invention, a brief summary of the present invention focuses on the convenience of tools and techniques not previously highlighted. For example, the present invention provides local-remote role reversal, implementation of a hot stand-by server using a "media not ready" signal, various alternative buffer contents and buffering schemes, Transactional, many-to-one mirroring using a "virtual" remote mirroring unit, identification of frequently accessed data based on the logged and analyzed behavior of the application, but without specific application knowledge, and It provides tools and techniques such as the use of unauthorized secondary servers.

The present invention relates to a computer system, a method for flexible data mirroring and a storage medium forming the same. As is well known, this application claims and encompasses several applications, including US patent application Ser. No. 09 / 438,184, the invention claimed in this application being directed to embodiments or other embodiments which would benefit from the invention claimed in the parent application. Can be used in the examples. The term "invention" is used herein in a manner consistent with the parent application, with the understanding that the claims define the invention in each application. Except where noted, the various terms used in both this application and the parent application are intended to be used in this application in a manner consistent with that used in the parent application.

As is well known in the present application, the present invention provides for non-invasive mirroring, with or without a dedicated communication link, and with or without a dedicated server or other server at the destination to assist the remote mirroring unit. Provide mirroring. In addition, the present invention provides many-to-one data mirroring, including mirroring from local servers running the same or different operating systems and / or file systems at two or more geographically dispersed locations. In addition, the present invention provides flexibility by allowing the use of various combinations of one or more external storage units and / or RAID units to maintain mirrored data. These topics have been addressed in particular in the parent application, and the discussion is reproduced below.

In addition, the present invention provides tools and techniques that do not address the same as the parent application. Embodiments include mirroring unit role shifts; Server hot standby mode implementation; An option for storing mirroring data; Storing and responding to SCSI commands related to modified data; Transactionality; Virtual remote mirroring unit; Application state recovery; And resynchronizing data volumes. These topics will be described with reference to FIG. 15 (which is not shown in the parent application), and it is noted that the relevant information provided for a given topic is not limited to FIG. 15 and a direct description thereof.

The invention may be embodied as a method, a system, and / or a storage medium forming the same. Although not specifically mentioned, a discussion of any one embodiment may apply to other embodiments. For example, a discussion of the system of the present invention will help to understand the method of the present invention that constitutes a system and / or method of transmitting data through such a system to mirror and vice versa. In particular, although FIG. 15 shows a flow diagram, it is not intended to limit the method but to help illustrate the media and systems constructed in accordance with the present invention.

Computer and general network

1 shows a network 100 in which a local server 102 is mirrored across a conventional route 104 to a remote server 106. The conventional route 104 is not limited to the telecommunications link itself, but rather to a modem, a data transmission unit, and other conventional tools and techniques used to transmit and / or receive data transmitted on such a link. Include. In particular, and without limitation, conventional route 104 may include a server interface, a link interface, and a DTU shown in FIG. 1 of US Pat. No. 5,537,533 and discussed in that patent.

In addition, conventional root 104 may include a small computer system interface (“SCSI”) performance extender, or a standard storage access network (“SAN”) connector. . Such devices require very high bandwidth links and minimum latency. They tend to have a distance limit of about 10 or 20 miles because the distance introduces latency. For example, the latency on a given SCSI extender in a single mode fiber configuration can cause the distance between the data source and the destination to be about 15 kilometers. The use of multimode fibers will reduce the distance to about 2/3 because of latency. Such a connection may allow only delays or disturbances of less than a few fractions of a second, or at most handle only a few seconds of delay as appropriate. These same problems apply to mainframe channel extenders.

As shown, network 100 is a configuration for mirroring according to conventional tools and techniques, but it is also one of many possible networks suitable for various applications and uses in accordance with the present invention. Such application will include various steps, according to the particular embodiment of the invention to be used. For example, the application disconnects the remote server 106 if no longer needed, replaces or replaces the conventional mirroring route 104 with the linked mirroring unit in accordance with the present invention, and mirrors the NLMs from the local server 102. Or unload other special software, further add a local server to be mirrored, and / or remote storage in the form of an external storage volume and / or a redundant array of independent disk ("RAID") units. It may include adding a. However, at least, the application involves the addition of at least one local mirroring unit and at least one remote mirroring unit, with remote mirroring units which can normally be linked to each other for the operation according to the invention.

Before and / or after its application, the network 100 may be connected to another network 108 including a LAN or WAN or part of the Internet or intranet through a gateway or similar mechanism. In the network 100 shown, the local server 102 is connected to one or more network clients 112 by a communication link or network signal line 110. Other suitable networks include multiserver networks and peer-to-peer networks. In a particular network, server 102 and client 112 may be uniprocessor, multiprocessor, or clustered processor devices. Each of server 102 and client 112 includes an addressable storage medium, such as a random access memory.

Suitable network clients 112 include, but are not limited to, personal computers; Laptop 114; Personal digital assistants (PDAs), and other mobile devices; And workstation 116. Signal line 110 may be a twisted pair, coaxial cable, or a portable link such as a fiber optic cable, telephone line, satellite, microwave relay, modulated AC power line, RF connection, network link, dial-up link, infrared link, And / or other data transmission “wires” or communication links known to those skilled in the art. Link 110 may implement a conventional or novel signal, and in particular may implement a series of commands and / or data structures for mirroring the data discussed herein. The remote server 106 stores the mirrored data obtained for the conventional root 104 on attached storage means such as an external hard disk and / or RAID subsystem 118.

Example of Flexible Mirroring Unit System

2 shows the invention in a system according to the invention. Unlike the conventional approach described above, the system according to this figure does not require a remote server. Local server 200 or some other host 200 communicates over local link 202 to local mirroring unit 204. Local mirroring unit 204 communicates over a journal link 206 with a remote mirroring unit 208. The local mirroring unit may include a spoofed packet generator for pre-approving data to the local server 200, and a nonvolatile data buffer 210 for maintaining mirrored data before being stored remotely. The remote mirroring unit has a destination nonvolatile memory for mirrored data received via local linking unit 204 into local mirroring unit 204. The remote mirroring unit may be physically separated from the local server 200 by various distances such as 10 miles or less, at least 10 miles, or at least 100 miles. These distances are merely examples; Because the present invention can take full advantage of the Journey link 9206, the system according to the present invention has no inherent distance limitation. Individual mirroring units will be described in detail below in conjunction with the description of flexibility in the exemplary system shown in FIGS. 2-12 and general components and operations.

However, some embodiments of the local mirroring unit 204 may be implemented by the local link 202 via the local mirroring unit 204, which appears to be a local server 200 or another host 200 as a SCSI disk or other conventional SCSI device. It includes SCSI emulation software and / or hardware to make a SCSI connection. This can be done by using within the local mirroring unit 204 a SCSI host adapter running in the target mode instead of the more common initiator mode. Suitable SCSI host adapters with this target mode include at least an Adaptec 2942940UW adapter, and a QLogic QLA-1040 adapter. In a similar manner, the local link 202 may be connected to a fiber channel connection, a USB connection, a mainframe channel extender, a V.35 CSU / DSU connection, a Fire Wire (IEEE 1394) connection, a memory type (e.g., AS, not disk / 400 mirror memory), IDE bus, PCMCIA connection, serial connection, Ethernet connection, Fiber Distributed Data Interface (FDDI) connection, or RAID subsystem to other standard buses and / or servers for connecting disks. Thus, conventional mirroring (in terms of copying to another local disk) allows hardware and / or software to be executed on a local server (as if the mirrored data is sent remotely to another local disk instead of being transmitted via the Journey Link 206). 200).

Unlike the far link in the conventional approach described above, the jonny link 206 need not be a dedicated secret telecommunication link. Although this link 206 is still used in some embodiments, the present invention also does not take into account the router's routerability or non-routerability, and does not take into account Ethernet, FDDI, V3.5, or other data link protocol, Internet protocol (IP). Or other network protocol, and / or mirroring unit 204 that communicates over a network, or a series of networks such as the Internet, using a user datagram protocol (UDP), a transmission control protocol (TCP), or another transport protocol, 208). Thus, the two mirroring units 204, 208 can be separated by tens or hundreds of miles if desired.

Journey link 206 serves as a data acquisition point through conventional link 104 and spoofing local mirroring unit 204. However, the Journey link 206 does not necessarily impose the requirements of high bandwidth and low latency that are frequently imposed by conventional links 104. Unlike a SAN, for example, a system using the Journey Link 206 can send mirrored data to a destination that is not limited to an element by a distance. Journey link 206 also provides shared bandwidth, as is common when traversing the Internet or wide area network. In addition, the Journey Link 206 and / or mirroring unit provide a system of the invention that has the advantage of a relatively high tolerance for interference and disconnection.

The described remote mirroring device 208 has a large buffer 212. As a result, the remote mirroring unit 208 can buffer the obtuse volume of the local server 200 or another host 200. In some embodiments the local mirroring unit 204 also includes a large buffer. In one embodiment, for example, the local server 200 volume and large buffers (local and remote) may each hold one terabyte of data in a nonvolatile memory. This buffering can be implemented, for example, by using the QLogic QLA-1040 adapter in the remote mirroring unit 208 or in the local mirroring unit to control one terabyte of data without requiring substantial modification. The complete volume image of the local server 200 can therefore be stored on a buffer in the mirroring unit

For added data recovery capability, an optional local mirror 230 can be created; This is generally a "complete" local mirror in the sense of being consistent and applicable but not necessarily fully updated. This local mummy can be performed in a variety of ways. This is not limiting, but the second port or second local mirroring unit 204 of the multi-ported local mirroring unit 204 for mirroring data to a “remote” disk subsystem that is substantially geographically close to the local host 200. ); Forking data in the local mirroring unit 204 below the disk emulation layer of the unit 204 to generate another locally transferred copy attached to the disk subsystem over a SCSI or similar bus; And using other conventional tools and techniques with local mirroring unit 9304 to create and manage local mirror 230.

Mirror 230 includes a copy of the server 200 volume to allow recovery in the event of a hardware or software failure. However, because the local mirror 230 is local, not remote, it does not provide the server 200 with substantial protection against natural disasters, civil unrest, terrorist attacks, physical destruction, and other geometrically localized risks. Do not. Thus, local mirror 230 does not provide the same degree of data protection as remote mirroring even if it includes other mirroring units 204 or otherwise implements the present invention. The local mirror 230 is connected to the mirroring unit 204 by a path 232 which may include a conventional link such as path 104 or a novel link according to the present invention. Although the local mirror 230 is not clearly shown in the other figures, one or more local mirrors may also be used in the systems shown in the other figures and other systems in accordance with the present invention.

For example, one approach utilizes Nonstop Networks Limited's or other technique of mirroring between two servers, and the local mirroring unit is used as the sole (primary) disk subsystem of the secondary server. Another approach is to do all the mirroring inherent in the pair of mirroring units by using the local mirroring unit as the sole disk subsystem to the host 200, with the local mirror 230 becoming the primary disk and the remote mirror being the only original. Functions as a mirror of This other approach is a less reliable configuration, but can provide high performance at low cost.

3 shows a system in which a local server 200 communicates with a local mirroring unit 204 over a local link 202. The local mirroring unit 204 communicates with the remote mirroring unit 308 via the journey link 206. Unlike the remote mirroring unit 208, which has a large nonvolatile buffer 212 that can hold data from the entire local server 200 volume, the remote mirroring unit 308 is for example 4 gigabytes less gigabytes. It has only a relatively small non-volatile buffer 310, such as buffer 310 that holds.

However, the system according to FIG. 3 includes a remote server 300 with associated nonvolatile internal or external storage. To illustrate this, FIG. 3 shows a RAID unit 312 that can be controlled by the remote server 300 at some point in time. RAID unit 312 is "hot-swappable", which means that a failed drive is taken from the RAID unit 312 and replaced while the computer 300 is running, and then the replacement drive File system structure and other data will be built automatically. The RAID unit 312 may in some cases be viewed as part of the server 300 and dedicated mirroring software on the server 300, as indicated by arrows from the RAID unit 312 to the server 300 in FIG. 3. It may be connected by conventional means, such as means comprising.

However, RAID unit 312 may be connected to remote mirroring unit 308 and server 300 by dual host connectivity in configuration 1400, which will be described in more detail below and shown in FIG. 14. have. The dual host connection may be used to service read requests from the first " normal mirroring " state where the switch from the passive remote server 300, the remote RAID unit 312 or other remote disk subsystem, is used only for mirroring. A second " " " " " second active " server having an active remote server 200 that serves a read request from the mirrored data of the remote RAID unit 312 or other remote disk subsystem. "Recovery" state.

In the first (general mirroring) state, the remote mirroring unit 308 receives data from the local mirroring unit 204 using, for example, Ethernet and / or TCP / IP connection 206. As mentioned in connection with FIG. 2, local link 202 may be a SCSI bus, USB, Fiber Channel, or similar connection. The remote mirroring unit 308 transfers data to the remote server 300 via the remote link 302 and the remote mirroring unit 308, or dual for the subsequent storage capacity of the RAID unit 312 that can be immediately backed up. If a host connection 1400 is being used, the transfer is directly from the remote mirroring unit 308 to the RAID unit 312. Since the remote link 302 may be a SCSI bus connection, for example, a remote mirroring unit 308 may appear on the remote server 300, for example, another "disk", RAID unit 312 by the remote server 300. SCSI disks are mirrored. Remote link 302 may also be a serial, Ethernet, FDDI, USB, Fiber Channel, or other general purpose connection.

The local mirroring unit 204 has a nonvolatile buffer that is similar to or identical to the small buffer 310 of the remote mirroring unit (except for specific data stored therein). Data from the local server 200 is notified in advance to the local mirroring unit 204 buffer. As far as the primary server 200 is concerned, the second "mirror" write has occurred locally. Indeed, the local mirroring unit 204 stores change data (or similar block level data) in these sectors and tracks until it can securely transmit data to the remote mirroring unit 308 via the Journey Link 206. The smart buffer of the local mirroring unit 204 stores any of the data described above that the Journey link 206 can handle locally. This data is stored in the local mirroring unit 204 until the remote mirroring unit 308 successfully writes to the remote server 300 and sends its confirmation to the local mirroring unit 204. Upon receiving this confirmation, local mirroring unit 204 erases the sector / track / block data from the successfully transmitted local nonvolatile buffer. Unlike conventional systems, no server 200, 300 necessarily requires NLM or other software specifically designed for data mirroring, as opposed to standard file system and operating system software.

4 shows a system with several components discussed above, as indicated using the same identification numbers in the figures. However, in the system of FIG. 4, the remote mirroring unit 408 includes both a small nonvolatile buffer 310 and a large nonvolatile buffer, the large buffer being immediately backable RAID directly connected to the remote mirroring unit 408. Implemented as unit 312. The small buffer 310 is used for buffer data received via the Journey link 206, causing the data to acknowledge to the local mirroring unit 204, and the data being sent to the large buffer 312 by the remote mirroring unit 408. Buffer the data until it is stored in. You do not need a remote server.

5 illustrates a system in which two or more local servers 200 write to the remote mirroring unit 508. In this and other figures, reference should generally be made to the local server 200 to include hosts 200 rather than servers. That is, the present invention can be used to mirror any host computer system 200 that will connect to the mirroring unit 204. Servers are well-known examples of suitable hosts 200, while other suitable hosts 200 are clusters, non-server computers, mainframes, and Storage Access Network ("SAN") or Networked Attached Storage ("NAS"). Data sources. The local server 200 or other hosts 200 may be physically separated from each other by various distances, such as 10 miles or less, at least 10 miles, or at least 100 miles. In the corresponding system for this figure, each local server 200 of a particular system uses the same operating system and file system platform, although other systems according to FIG. 5 may use different platforms. For example, each server 200 may be a Novell NetWare server on one such system, and each server 200 may be a Microsoft Windows NT server using the NT File System (“NTFS”) on such another system.

Each host 200 of the system is connected to its own local mirroring unit 204 by SCSI, Fiber Channel, USB, serial line or other standard storage subsystem or other peripheral connection 202. The local mirroring unit 204 is connected to the single remote mirroring unit 508 by the journey link 206. Remote mirroring unit 508 has a SCSI, Fiber Channel, USB or similar controller card for each local mirroring unit 204.

Data from each remote mirroring unit 204 can be individually instantaneously backed up in a RAID storage unit 312 of a group of RAID units 512 by SCSI, Fiber Channel, USB, or similar connections within the remote mirroring unit 508. Can be sent directly (ie, not via a remote server). The RAID unit 312 may be physically external to at least a portion of the remote mirroring unit 508, such as a portion that includes Ethernet for connecting to the Journey Link 206. However, the remote mirroring unit 508 is defined by functionality rather than packageability. In particular, the RAID unit 312 is considered part of the remote mirroring unit unless otherwise indicated (eg, discussed in FIG. 14). Each RAID storage unit 312 has a remote bootable volume and writes data in a sector / track or block manner. In addition, the illustrated remote mirroring unit 508 includes a small buffer to enable response and buffering of data received via the Journey Link 206.

FIG. 6 shows a system similar to that shown in FIG. 5, but the remote mirroring unit 608 writes an externally bootable storage volume 614 to its volume group 616. The local server 200 running on the same platform actually writes to the "disks" which are the local mirroring unit 204, and in turn writes data to the remote mirroring unit 608. The remote mirroring unit 608 has a SCSI, Fiber Channel, USB or similar controller card and bootable storage volume 614 corresponding to each local mirroring unit 204. Data from each local mirroring unit 204 will be transferred directly from the remote mirroring unit 608 to the corresponding storage volume 614 using a SCSI bus or other data line. Each volume 614 is a remote bootable volume and writes data in a sector / track or block manner.

In general, in an alternative to the system according to FIG. 6, or in another system as well, a separate disk 614 (eg, FIG. 6) corresponding to the mirrored data to hold the mirrored data of each local server 200. Instead of retaining in a separate RAID unit 312 (as in FIG. 5, for example) or a separate partition may be used. In various many-to-one systems, it is necessary to branch itself as if making a new connection and start the process of fixing the volume mirror from multiple mirror attempts using IPC or other mechanism. .

7 illustrates a system in which the remote mirroring unit 708 includes both individual external storage volumes 614 and RAID units 312. The mirrored data is stored on both sides of the storage subsystems 312 and 614 by the remote mirroring unit 708, providing additional assurance that the data is available when needed.

FIG. 7 illustrates a system in which two or more local mirroring units 204 write to one remote mirroring unit 708, with several remote storage units 312 or 614 as shown in FIGS. 5 and 6, respectively. Instead of dividing the mirrored data among all the mirrored data, all the mirrored data for several local servers 200 are mounted on one large storage volume (312 or in various embodiments) directly mounted on the remote mirroring unit 708. 614 or both). The volume used by the remote mirroring unit 708 has a split for each local mirroring unit 204. Each partition provides a remote bootable "volume" and writes data in sector / track or block fashion as usual.

In the alternative system illustrated in FIG. 7, the mirrored data is divided between two or more storage units that are directly connected to the remote mirroring unit 708, where a given storage unit is for a given local mirroring unit 204. Holds mirrored data. However, unlike systems that use only RAID units (FIG. 5) or only external disks (FIG. 6), a mix of external disks 614 and RAID units 312 is used. For example, external disk 614 holds data from first local mirroring unit 204, and RAID unit 312 holds data from second local mirroring unit 204. In such a system, the remote mirroring unit 708 has a SCSI, Fiber Channel, USB, or similar controller card corresponding to each local mirroring unit 204, with data from each local mirroring unit 204 being individually external. It will be sent directly (without a server, such as server 300) directly to SCSI, Fiber Channel, USB, or similar communication lines to RAID unit 312 or external bootable drive 614 that can be immediately backed up.

FIG. 8 illustrates a system as discussed in connection with FIG. 5. However, in the system of FIG. 8, local servers 200 depend on various platforms, as indicated by some numbers 822, 824, 826. Of course, the system according to this or other figures has exactly three local servers 200 and corresponding local mirroring units 204, which are each paired with only the server 200 and corresponding local mirroring units 204. It has two or more pairs. For example, one system according to FIG. 8 includes a Novell NetWare server 822 and a Microsoft Windows NT server 824, while another system according to FIG. 8 includes two Novell NetWare servers 822 and 826 and a Microsoft Windows. NT server 824 is included.

9 illustrates a system such as discussed in connection with FIGS. 5 and 8. However, unlike FIG. 5, local servers 200 depend on various platforms, and unlike FIG. 8, a remote mirroring unit is a group of external disks 614 instead of a group 512 of RAID units 312. Unit 608 using 616.

FIG. 10 shows a system as discussed in connection with FIG. 7. However, local servers 200 in the system according to FIG. 10 depend on various platforms. As in FIG. 7, the local mirroring unit 204 may be mapped to a partition or storage unit in some systems. When mapped to a partition, the local mirroring unit 204 may be partitioned within the RAID unit 312, partitioned within the external drive 614, or partitioned within the RAID unit 312 to be mirrored to the external drive 614. Can be mapped to. When mapping the local mirroring unit 204 to a storage unit, one or more local mirroring units 204 transfer their data through the remote mirroring unit 708 to the corresponding external drive (s) 614, while one The above local mirroring unit 204 transfers their data through the remote mirroring unit 708 to the corresponding RAID unit (s) 312.

11 illustrates a system for mirroring data to one or more remote locations. Figures 5-10 show a "many-to-one" mirroring system (one or more local servers are mirrored to one remote destination) while Figure 11 shows a "one-to-many". In the sense of showing a mirroring system (one local server is mirrored to one or more remote destinations), these systems are the counterparts of the systems shown in FIGS. In general, the local mirroring units 204 will all mirror the same data, but using various local mirroring units 204 means that the mirroring across at least one Journey link 206 may be defined by the local mirroring unit 204. Do not continue to disturb even though is not available. The local link 202 may all use the same type of connection or may use other connections. For example, one local link 202 may be a SCSI connection while the other local link 202 may be a USB connection. Journey link 206 may be uniform or variable. Similarly, the remote mirroring units may each have the same components (eg, each may use a RAID unit 312) or may use other components at different locations.

FIG. 12 illustrates a system similar to that shown by FIG. 11 in that data is mirrored again at two or more remote locations. However, the local mirroring unit 204 of FIG. 12 is a multiport mirroring unit. In other words, one or more Journey Links 206 can be simultaneously connected in a manner similar to the conventional connections of a multi-port server. The multi-port mirroring unit 204 transfers mirror data from the host 200 over each connection 206, thereby helping the host 200 to mirror to several remotes that may be miles apart from each other. The multi-port local mirroring unit 204 requires only one local buffer and optionally includes a full local mirror 230 like the mirroring units 204 of other systems.

Additional Notes on Mirroring Units

The components and operation of the mirroring unit have been described with reference to FIGS. 2 to 12 above. Certain additional information provided below is not necessarily related to every mirroring unit of every system according to the invention, but nevertheless this additional information is responsible for ensuring that the mirroring units accurately mirror the data. It is helpful to understand how to allow more flexibility for companies and people.

At least some mirroring units can reliably emulate connected disk drives by similar connections via SCSI, Fiber Channel, USB, or standard server drivers running on Novell NetWare and / or Microsoft Windows NT platforms. SCSI, Fiber Channel, USB, or similar emulation in other operating systems may also be provided.

Each of the local and remote mirroring units is preferably configured to support I / O via a monitor, a keyboard, and a mouse plugged into it. Some mirroring units have a network address, but others do not allow a network administrator to access a particular mirroring unit on the adapted network 100 via a web browser or other means on the remote station 116.

The mirroring unit is preferably a good Simple Network Management Protocol ("SNMP"). The network administrator has remote access to both local and remote mirroring. The mirroring unit 204 software provides an interface for monitoring the utilities. In particular, each local mirroring unit 204 may be configured to determine the number of writes / reads to the local server, the state of each local server 200, the number of restarts / warm starts of each local server 200, and the like. It acts like a network broker in terms of tracking and generates SNMP traps when needed. By the local mirroring unit 204 the next data, ie the number of blocks of the current buffer 210, an alarm when the buffer 210 fills and / or when the buffer crosses some specific threshold, the server 200 starts up The number of blocks transmitted after the galling and the number of blocks received since the server is started can be provided to the manager.

In addition, some local mirroring units 204 have an incremental dial-up option. If a customer uses the mirroring unit 204 with a dial-up connection and does not want to connect at all, the unit ( 204 provides an option for transmitting data over the jonny link 206 at a particular time. In addition, the local mirroring unit 204 may have a setting to disable transmission of data during periods of high traffic in the adapted network 100 or other portions of the journey link 206. The buffer 210 of the local mirroring unit 204 should be large enough to buffer the data received from the local server 200 during this non-transmission period.

More generally, the local mirroring unit 204 matches the performance of the high speed RAID disk subsystem, preferably in terms of data transfer rate, reliability, and compatibility with existing platforms on the server 200. Local mirroring unit 204 preferably includes special purpose hardware, since implementation in software is unlikely to meet this performance goal. Design and configuration of suitable hardware and software, including any necessary firmware, may include conventional mirroring path 104; SCSI controllers, or similar controllers, Fiber Channel, USB, or other controllers identified herein; Individual known subsystems, such as buffers 210, 212, 310, disk 614, and RAID unit 312, and their interfaces; Software such as FreeBSD drivers; Ethernet and other known Network Interface Cards (“NICs”); Network protocols such as Ethernet and TCP / IP protocols; Description and examples provided herein; And other tools and techniques now or later available to those skilled in the art, can be accomplished by those skilled in the art.

Writes to the local mirroring unit 204 should generally be acknowledged and written to the local buffer 210, although such local mirroring is not clearly shown in FIGS. The path may be written to a fully local mirrored volume 230. For performance, it is generally accepted to buffer writes either through the RAM cache of the local mirroring unit 204 or through a local server, or both. In particular, implementations may use the available hardware RAID unit 312 cache or other SCSI, Fiber Channel, USB, or similar caches. Reads from the local mirroring unit 204 should generally be serviced with the appropriate data from the local mirror 230.

After a crash or reboot or any other kind of service interruption, when the local mirroring unit 204 comes back online, the local mirroring unit 204 is moved from its local buffer 210 to the remote mirroring unit 208, 308, 408, 508. , 608 or 708 will automatically begin transmitting data. Data written to the buffer 210 of the local mirroring unit must be transmitted to the remote mirroring unit in a first in first out manner via a network or other Journey link 206. This can be done using TCP / IP or other Journey link protocol. The remote mirroring unit preferably maintains a perfectly matched mirror so that the remote volume is always usable and mountable by the operating system, regardless of mirror synchronization status.

At least, in embodiments using FreeBSD based software, kernel panics should not occur on the local mirroring unit 204 unless there is an inherent failure of the hardware or software to mirror inherently. Operational errors in the local mirroring unit 204 software should preferably not cause system shutdown and should not cause any behavior of the host server 200. Preferably it is possible to reconfigure the mirroring unit software without rebooting, the number of unique versions entails changing each software. Thus, the software preferably reads all the initialization information and thus configures itself through system calls available to the administrator without disturbing the data processing by the mirroring unit. It should not interfere with the host server 200. The local mirroring unit 204 determines whether the remote mirroring unit is online from the host system 200 if the local buffer 210 is not filled and whether the network or other Journey link 206 bandwidth is available. Whether to approve the entry preferably.

Once the local buffer 210 is filled, the local mirroring unit 204 preferably continues to maintain the local mirror 230 (if present), and preferably continues the circular queue from the local buffer 210. Dequeue. However, the local mirroring unit 204 preferably stops adding to the queue until instructed by the user (usually an administrator) to begin queuing the process again. System calls rather than reboots preferably prevent the user-space process from queuing the local buffer 210.

The mirroring unit preferably autodetects the disappearance and reconnection of the network or other Journey link 206 bandwidth. For example, if there is enough space in the local buffer 210 to hold data changes accumulated while the local mirroring unit 204 disconnected, disconnect the Ethernet cable of the local mirroring unit and reconnect it the next day. Doing so preferably causes zero data loss and does not require arbitration at the part of the network operator.

The mirroring unit or monitoring software associated with these units preferably determines whether the system has been shut down cleanly after preboot, so that the monitoring software determines the likelihood that the remote mirror is out of sync. The local mirroring unit 204 preferably loses as little data as possible in the case of a power failure. Thus, some mirroring units include an Uninterruptible Power Supply ("UPS"). Assume that there will be time to send RAM-buffered writes to the local mirror (if present) and / or to the local buffer 210 in case of power loss.

In one embodiment, the mirroring unit operating system (eg, FreeBSD) boots in read-only mode from the hard disk to avoid the filesystem that FreeBSD itself has. The configuration data can be stored in small portions and sent from the same information on the mirroring unit peer or by sending an SNMP alert that the mirroring unit has lost the configuration data and will be offline until it is recovered. have. If the peer mirroring unit cannot be reached, an alert can be used. In some embodiments, a disk drive avoids a controller card initialization routine that does not perform itself, for example to avoid bus reset. Also, if the mirroring unit buffer is filled, it is desirable to simply acknowledge the write and mirror the write locally while sending the alert that the buffer is full and the remote mirror is out of sync with the local mirror.

As noted above, it is desirable to cold-reboot the local mirroring unit 204 without interfering with the host system 200, particularly with respect to SCSI, Fiber Channel, USB, or similar handshaking. It is possible to. The buffer 210 of the local mirroring unit maintains the order of the write requests and sends them to the remote mirroring unit in the same order received by the local mirroring unit 204, thus always preserving data consistency.

The remote mirroring unit receives a TCP Protocol Data Unit (hereinafter referred to as a TCP packet) from, for example, the local mirroring unit 204 and sends them to the disk subsystem (external drive 614 or RAID unit 312, etc.). The drive is write-at least logically, if any, block-for-block as if it were the local mirror 230 and the previous host 200 volume. The mirrored data may be out of date, but this must be consistent.

For the purpose of data recovery, the remote mirroring unit software preferably has an interface to user-space such that the user-space program is inhibited or refunctioned by the mirroring unit software for reading, writing and / or retrieval of the remote mirror. Enable the remote disk subsystem, and thus mirrored data, to be accessed by a second SCSI host on the same chain. At the remote site, the remote mirroring unit and backup host server will be attached to the shared disk subsystem. For example, the remote mirroring unit may use the SCSI ID 6, and the remote server used for the restoration uses the SCSI ID 7. While the remote mirroring unit is mirroring, the remote host will leave the shared drive unmounted. For data recovery, as part of the switchover, the remote mirroring unit stops accessing the shared drive and the backup host server can mount it.

The remote mirroring unit preferably informs the user-space program of the number of blocks received from the local mirroring unit 204. The remote mirroring unit mirrors to the disk subsystem so that the volume can be mounted by a host system having the same operating system as the local server 200. When the remote mirroring unit receives a request from local mirroring unit 204 and writes to logical block number N, data must be written to logical block number N on disk subsystem 312 or 614 of the remote mirroring unit. Write requests from the local mirroring unit 204 to the disk subsystem 312 or 614 of the remote mirroring unit in the order received by the local mirroring unit 204 to preserve data consistency.

In the Journey Link 206, the communication between the local mirroring unit 204 and the remote mirroring unit can use the TCP protocol because they feature error recovery and transmission guarantees. The remote mirroring unit software operates as a TCP server, and the remote mirroring unit 204 operates as a client of the remote unit. Loss of network bandwidth or connectivity preferably does not interrupt the local mirroring unit 204 or the remote mirroring unit. Likewise, data recovery at a remote location preferably does not interrupt local mirroring unit 204. If the connection between the local mirroring unit 204 and the remote mirroring unit expires or is lost, the local mirroring unit 204 preferably tries to reconnect until the connection is reestablished. The local mirroring unit 204 then continues the transmission of the mirrored data, preferably stopped, otherwise resumes normal operation.

The mirroring unit of the present invention is more "intelligent" than the original Off-SiteServer product, which is an implementation of an improved operating system based on the FreeBSD UNIX operating system. Improvements include adapting the driver for the QLogic SCSI controller to emulate the disk drive by allowing the card to operate as a SCSI target rather than as a host, although other controllers can also be used with the appropriate drivers. The boot process has also been modified to show the mirroring unit configuration utility on the console instead of the login prompt, and the kernel has been recompiled. Each mirroring unit 204 at the source is running an operating system that allows it to run completely independently of the host server 200. One of the resulting flexible mirroring features is that the mirroring unit 204 does not require initialization or connection software on the host server 200 (in the original Off-SiteServer product, this software takes the form of Vinca NLM). ).

Instead, the mirroring unit 204 operating system emulates a SCSI or other standard disk or data acquisition point. The mirroring unit 204 may thus be mounted as a mirrored SCSI disk, for example, under any SCSI supported operating system including at least Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows NT, Novell Netware, FreeBSD, and Linux operating systems. have. Disk emulation should preferably be performed (at least in terms of server 200) in addition to disk reading and writing, in addition to any standard disk operations including handling server 200 requests for disk formatting, disk partitioning, disk defect checking such as scan disks, and the like. Is performed for the possible points.

The system according to the present invention may also maintain a locally full mirrored volume 230 against fault tolerance. Since this mirroring operation may occur by mirroring unit 204 by branching the data down the emulation layer of software (or by performing two writes), mirroring unit 204 may also cause this local volume 230 to be sequential data. It can be kept with a change buffer. This allows the mirroring unit 204 to service local reads by the server 200 without excessive delay, thereby allowing the system to run without disk handicap and no split detection software, eliminating potential software compatibility issues. have. This also allows the system of the present invention to reverse mirror data to the local disk of the server 200 during local disk mirroring instead of going through the journal link 206. Also, if local mirror 230 is maintained, local mirror 230 does not suffer from the delays and risks associated with transmitting mirrored data over the Johnny link 206, so that local mirroring unit 204 is responsible for the host ( There is no need to include a spoof generator to pre-check the reverse record for 200).

The mirroring unit according to the invention typically comprises operating system software. Thus, at least some mirroring units may execute multiple "host" applications to manipulate the acquired mirroring data. The system may also be scaled up or down using drivers and / or other suitable software and / or hardware to meet the requirements in a particular environment. For example, processes can be distributed among multiple processors, SCSI cards, and / or other "intelligent" devices to handle more activity and workload. Similarly, the system can be scaled down to reduce costs while satisfying the need for a lower performance environment. The local mirroring unit 204 with appropriate software can operate as a separate intelligent disk subsystem or can emulate the host 200 operating system as a fail-over to a local fault tolerance. Local disk volume 230 may serve as a local mirroring replacement for local fault tolerance in the event that host 200 disk subsystem fails.

The system maintains consistency and availability at the remote location in part by an intelligent buffer 210 that maintains and transmits data in a first-in, first-out manner. In this way, the data blocks are sent to the remote in the exact order they are received via the emulation layer at the local mirroring unit 204. Since the packet data does not have to arrive at the destination in the same order in which they were sent, sequential numbers and / or time stamps may also be used.

Some embodiments use the following approach with circular buffers and other means for protecting data in shutdown. In addition to the QLogic card used as a disk target emulator, the local mirroring unit has two disk systems attached via a local SCSI disk controller. One disk has a host operating system (eg FreeBSD 3.1) with associated utilities and mirroring unit management software. This disk also serves as a buffer 210 disk. The other disk system attached to the mirroring unit is at least as large as the host 200 disk being mirrored, and serves as a local mirror 230 of the host 200 disk.

SCSI data is read from the QLogic card and emulated in the kernel upon read or write request. Read requests coming from QLogic cards are preferably performed using local mirror disk 230 and are not transmitted over network 206. The write command is copied directly to the local mirror disk 230 and added to the circular queue of a buffer disk or nonvolatile RAM as well as acknowledged to the host system 200 as soon as possible (but need not be acknowledged in advance). .

Each time one block is written to the circular queue, two blocks are actually written sequentially, one is the actual data block to be transmitted, and the other is the LBN (logical if possible) for the current tail pointer to the queue. Timestamp with other data, such as number of blocks). This second block is the so-called metadata block. This approach is not space efficient, but it reduces the number of disk writes needed to maintain the queue pointer. The queue pointer may also be maintained by keeping a copy of this nonvolatile RAM and possibly the entire circular queue if there is available nonvolatile RAM. One way to save space and time is to write a larger chunk at a time to a circular buffer and buffer the block in memory until it has accumulated enough to be able to write. This makes it possible for meta data blocks to be used for many data blocks, reducing the number of disk write operations and saving disk space.

In the case of system shutdown and restart, the head of the queue is found by searching for the block with the most recent time stamp in that metadata segment and using that metadata segment to find the tail point. This can be done, for example, by doing a binary search. Since the buffer implementation is circular, there is no need to physically remove the transmitted block from the buffer (ie by erasing or zeroing the block), and the increment of the tail pointer does this effectively. A buffer pool condition is detected when the head pointer is one less than the tail pointer. A pointer refers to a location in the circular buffer and does not refer to data in the buffer itself (ie it is a linked list, not an array).

Having the most recent seconds may not be necessary to maintain a 64-bit time stamp because it may be sufficient to determine the last block written before system shutdown. For example, suppose four blocks were written in the same second and have the same time stamp. Then, the last block according to the time stamp is an ordered list and thus the last written block. If the time stamp is too computationally expensive, a simple incremental counter may roll over over faster than 2038, but will be enough. The queue buffer size varies with the rate of change of the end user's data and the length of time the customer needs to resist the outage of the network 206. The queue buffer can be as small as a few hundred megabits or as large as the host volume being mirrored. There is no inherent limitation on the minimum or maximum size of the buffer, and the buffer may need to be larger than the host volume being mirrored if high data change rates and frequent long interruptions of the Johnny Link 206 are expected.

Individual processes, which can run in user space or system space, read the blocks from the circular queue and send them over the network 206 to the remote mirroring unit. This transfer process can convey the queuing process at a time instant relative to the current pointer position of the process and monitor the time stamp to determine when the queue is empty. In worse cases, if the number of retransmissions does not increase excessively in the case of a system restart, the system will terminate retransmission of a number of blocks that have already been transmitted, which may be good if the tail pointers stored in the metadata are somewhat outdated. . Preferably the transfer process may determine the number of blocks after server startup. In some cases, it can be assumed that the buffer can buffer the entire host volume. Instead of taking the risk of slowing down the SCSI bus under the "do no harm" idea, it would be better to simply dump data that does not fit in the already filled queue and notify the user space monitoring process of this event.

To reduce the number of retransmission blocks, the system can check the writes to the local mirror and, if they are really different, just add them to the circular buffer, avoiding any lazy write problems. This can be achieved by maintaining a hash table of checksums for each LBN on the disk, one tradeoff will be processor time computing the checksum and memory versus additional disk operation.

Common way

13 and 15 illustrate the method of the present invention for remote data mirroring. Some methods include installing mirroring units, for convenience, these steps are collectively identified as steps within installation step 1300. For example, the system integrator, mirroring equipment vendor, and manager may be authorized to perform some or all of the steps shown in step 1300 when installing a system such as those shown in FIGS. Another method of the present invention includes steps for transmitting data to one or more mirroring units, for convenience these steps are collectively identified as steps in step 1302. These transfer steps may be performed under the permission with test data by the installer as part of the installation step 1300, but may also be routinely performed with mission-critical data at the command of a regular user of the system in accordance with the present invention.

During the attach step 1304, at least one server 200 is connected to at least one local mirroring unit 204. As mentioned above, this connection may be in the form of a SCSI bus, a fiber channel connection, a USB connection, or some other standard disk subsystem bus. Since one local mirroring unit 204 emulates a disk subsystem, the connection during step 1304 is basically the same as the connection of a conventional disk subsystem to the server 200, at least in terms of the server 200. In particular, no special mirroring NLM or other mirroring software installation is required.

At least one mirroring unit 204 is connected to at least one corresponding Johnny Link 206 during the attaching step 1306. Depending on the situation, this may involve various actions. For example, if the Johnny Link 206 includes a local area network, the local mirroring unit 204 may be connected to the same network as other network nodes, and SNMP support may be configured. Dial-up parameters are configured when the Johnny Link 206 includes a dial-up connection from the local mirroring unit 204. Similarly, when the Johnny Link 206 includes a dedicated personal communication such as a T1 line, a familiar operation is made to establish a connection.

At least one remote mirroring unit 208, 308, 408, 508, 608, or 708 is connected to at least one corresponding jonny link 206 during the attach step 1308. This may generally be accomplished in the same manner as the connection of the local mirroring unit 204 during step 1306. However, when the remote mirroring unit operates as a TCP server in a given environment, the local mirroring unit 204 acts as a client of the remote mirroring unit. Thus, in this embodiment, connection step 1306 connects a TCP client and connection step 1308 connects a TCP server.

During the test phase 1310 a test is made on the mirroring unit. These tests, for example, compare the processing performance of the local mirroring unit 204 with the performance of the RAID unit, mirror data back from the remote site back to the local site, and insert incorrect configuration information into the local mirroring unit 204. Modify this information, reboot the local mirroring unit 204, disconnect the Johnny Link 206, interrupt power to the local mirroring unit 204, and interrupt power to the remote mirroring unit. And overflowing the buffer 210 of the local mirroring unit 204 and performing another test. Specifically, without limitation, test step 1310 includes performing one or more tests described in the "Test Suites" section of this specification. Test 1310 also includes transmitting data as described below in connection with step 1302, but the test is shown as a separate step in FIG. 13 for clarity.

The transmission step 1302 may include a transmission step 1312 of transmitting data from the server 200 to the local mirroring unit 204 via a standard bus. This is because the present invention provides a mirroring unit that emulates a disk or RAID subsystem unlike the conventional path 104.

During the transmission step 1314, the mirrored data is transmitted over the Journey link 206. This may be done with a dedicated link as in the case of conventional path 104, but with standard protocols such as Ethernet and / or TCP and / or other open standard protocols and conventional networking infrastructure associated with them such as local area networks and / or the Internet. Can be done using the facility.

In an embodiment, the mirrored data is time-stamped by the local mirroring unit 204 to maintain a record of the order in which the blocks of data are mirrored and to associate this data to a specific point in time. Instead of simply maintaining a current copy of the mirrored volume, the remote and / or local data storage is large enough to maintain one or more snapshots of the mirrored volume and incremental changes at the sector / track / block level for that volume. Linked. In a preferred embodiment, only one snapshot is needed. The single snapshot provides a baseline and subsequent changes are journaled so that the state of the volume can be restored at any desired point (which will be journaling granularity). The journal can be arbitrarily large, with additional storage space added as needed to maintain it, or maintained in a fixed size FIFO circular buffer, so that old journal entries are replaced by new journal entries after the journal buffer is initially filled. Can be overwritten. More generally, the appropriate remirring software and snap-tos and (if necessary) incremental changes can be used later on to reconstruct the mirrored disk volume as it existed at a particular previous time.

During the transmission step 1316, the mirrored data is transmitted to a remote mirroring unit without a server. This configuration is illustrated in FIG. The remote mirroring unit has hardware and functionality common to conventional servers, but not conventional servers. Servers provide more general functionality than mirroring units. The mirroring unit concentrates on efficiently providing substantially continuous near real time remote data mirroring. The remote mirroring unit functions similarly to the remote mirroring server with respect to the acquisition of data via the journal link 206, but otherwise very similar to the mounted disk. In particular, the remote mirroring unit functions similarly to a disk or RAID unit in this case where a secondary server is attached. If the remote mirroring unit needs to re-mirror all data back to the local server 200 via the journal link 206, then no secondary server is needed for this.

After data is sent from the local mirroring unit 204 to the remote mirroring unit of the destination, the remote mirroring unit can do various things. For example, the remote mirroring unit may convert the received data packet into data blocks written to a single external disk 614. The remote mirroring unit can convert these data packets into disk blocks and write them to an internal disk subsystem and / or disk partition. The remote mirroring unit receives the packet data, converts it into disk data blocks, and writes it to the RAID unit 312 in the form of an external data subsystem, where the data is stored on a plurality of " intelligent " disk subsystems. Use internal striping (RAID) software to stripe data across the disks. This conversion from packets to disk block data and to striped (RAID) data also takes place through the hardware controller and associated drivers, along with storage for the external “intelligent” disk subsystem. The remote mirroring unit can also write to an external intelligent RAID subsystem 312, where the disk blocks are written to the disk subsystem as data streams and striped by the intelligent RAID subsystem.

Rather than writing the received data to the remote mirror 312 or 614 immediately, the remote mirroring unit first writes the data to the remote buffer and then the type of "signature" of the data (checksum or cyclic redundancy check value). Can be sent back to the local mirroring unit. The local mirroring unit then ACK-ACKs or NAK-ACKs the data (based on the confirmation of the signature), and only when receiving the ACK-ACK from the local mirroring unit, the remote mirroring unit transfers the data from the remote buffer to the remote mirror. Will pass. In such embodiments, if the remote mirroring unit receives the original signature as well as data from the local mirroring unit, the remote mirroring unit will NAK the original data transmission if the original signature is not correctly verified.

More generally, several methods for ACKing data are possible. For example, one person may consider the remote mirroring unit and the local mirroring unit to be equivalent, or may view one as another subsystem. In this case, on the remote mirroring unit, the ACK will come from the remote mirror disk itself (possibly from its cache), and on the local mirroring unit, the ACK will come from the local mirror disk itself (possibly from its cache). However, on a local mirroring unit, ACK will not be needed from the remote mirroring unit, only from the local end of the Journey link before ACKing the host. On the local mirroring unit it would be wise to wait for an ACK from the remote mirroring unit before removing the blocks from the local buffer, but this can be done after a long ACK of the host.

Additional steps are possible if at least one secondary server 300 is present in the system. For example, the remote mirroring unit may relay data directly to the remote server 300 through the server's network operating system. This operating system can be in an active or passive state. In either case, data received via connection 302 may be written to an internal local disk subsystem via server 300 operating system. This method requires special software for each operating system at the remote point. The remote mirroring unit can also use an internet-based data window to send and receive data between the remote mirroring unit and the secondary server 300. This data window may be through an Internet component extension to the core operating system, such as a plug-in extension to the browser interface or a MicrosoftActiveX extension.

In the above description, the local mirroring unit may be “intelligent” enough to relay the mirrored data to one or multiple remote mirroring units. A one-to-many system as shown in FIG. 12 has three remote mirroring units connected to a single multi-ported local mirroring unit 204 by respective Journey Links 206, the multi-port mirroring unit being shown here. In other systems according to the invention it may be used similarly or in combination with single-port mirroring units. There is no severe limitation on the number of remote mirroring units in a given system.

The remote mirroring unit can also relay the mirrored data to the near-field mirroring unit and / or other farther remote mirroring unit for greater error tolerance. The remote mirroring unit acts as a coordination relay that coordinates the load balance between two or more of the following remote mirroring units to balance the load and provide error tolerance, with proper attention to the continuous consistency and completeness of the data mirrors. Can be. The N remote mirroring units may be connected to each other to provide improved error tolerance and may have the same network address or domain naming system ("DNS") name. Combinations of these various methods can also be used.

In an embodiment having one or more separate nuclearly independent remote disk subsystems connected to the remote mirroring unit, the remote mirroring unit functions like a SCSI master (for example) and writes data to the remote disk. If there is a secondary server 300, the server 300 follows both the remote mirroring unit and the remote disk subsystem in the SCSI chain. During data mirroring, secondary server 300 is typically slave and / or passive. In the event of an error of the mirrored local server 200, the remote server 300 mounts the external volume and becomes the SCSI master. At the same time, the remote mirroring unit dismounts its remote disk subsystem driver and goes into a passive (slave) state.

In particular, this may be accomplished using a configuration such as shown in FIG. 14, which includes a “dual host” connection 1400. In many conventional methods, only one host adapter is typically on a SCSI chain such as LUN 7. During power up or reset, the host cycles through all the other LUNs to determine what is connected. If the system uses dual host adapters, the second host is typically on LUN 6, which will only reset or query LUN 0-5. Thus, LUN 7 is considered the primary host and LUN 6 is considered the secondary host. In any event both hosts have "access" to underlying targets when connected as shown in FIG.

The dual host connection itself is not new. In particular, dual host connectivity between BusLogic EISA cards and Novell NetWare servers is known. However, the inability of this Novell server to refresh its file allocation table on demand makes the functionality provided by the dual host connection in this case practically meaningless. General information about dual host connections includes an online SCSI FAQ, including It is open to the public. If dual host connectivity is not used, the remote server 300 requires a driver, NLM, and / or other software dedicated to mirroring so that the remote server 300 can receive the mirrored data directly from the remote mirroring unit and possibly do so later. Can be saved for use.

In an embodiment in accordance with the present invention using dual host configuration 1400, remote mirroring unit 208, 308, 408, 508, 608, or 708 is a RAID unit until commanded to abort for the switchover to take place. 312 or other remote disk subsystem. During this time, the remote mirroring unit performs remote data mirroring and sends data to the RAID unit 312 as described herein as the SCSI master. During this time, Novell or another secondary server 300 is in a passive (dismounted) state. This avoids the damage that would otherwise be caused by writing the server 300, remote mirroring unit, and RAID 312 or other remote disk subsystem together in this one-way manner shown in FIG.

To switch, the remote mirroring unit dismounts the RAID unit 312 and the server 300 mounts the RAID unit 312. The server 300 then becomes a SCSI master. The remote mirroring unit preferably has a secondary host position (LUN (6)) because it may not necessarily be expected or feasible to select a secondary server SCSI card. When two machines appear, the remote mirroring unit will experience a second reset when its driver is powered up. This is normal, but the remote mirroring unit must be recoverable at the device driver level. By using the dual hosting (not dual channel) method, cabling becomes a normally terminated SCSI chain and no more hardware is required. The switchover can be fully accomplished by software through storage subsystem and / or driver dismounting, mounting, and related operations.

The previous discussion can be seen to implicitly assume a one-to-one relationship between the remote mirroring unit and the secondary server 300. However, a software or mechanical SCSI switch (e.g.) may be employed to connect the remote mirroring unit to some potential host servers 300. In protocols such as fiber optic channels and / or in SAN architectures, there is no traditional SCSI master / slave relationship. Instead it is an address relationship that occurs through DNS and / or numeric addresses. In such a system, the transition occurs via an address change and the remote mirroring unit will still go passive.

The remote mirroring unit can be made to operate a complete network operating system. In the event of a disaster, the remote mirroring unit can be active and become a fully functional server for information about the disk subsystems that send the mirrored data. The remote mirroring unit can also run an emulation program that allows the local site to emulate a server under a particular host operating system. The remote mirroring unit may also run a program for shutting down the operating system adopted under mirroring, and any related programs, and then restart from a separate internal disk or separate partition under a particular host operating system.

The remote mirroring unit can also be enhanced to continue running as a secondary server rather than normally dedicated only to data mirroring. However, doing so can seriously reduce mirroring performance, as well as increase the risk of mirroring failing completely.

If the remote mirroring unit has essentially the same software as the local mirroring unit 204, the remote mirroring unit can function as the local mirroring unit 204. For example, when mirroring from site A to site B from site A, the mirroring unit of site B is a remote mirroring unit for site A and a local mirroring unit for site C. The remote mirroring unit can also function as the local mirroring unit 204 in restoring from the remote point back to the source. That is, when mirroring from site A to site B, the mirroring unit of site A is local, and the mirroring unit of site B is remote, but when restoring data from site B to site A, the mirroring unit of site A is remote and site The mirroring unit of B is local.

Finally, some inventive systems can accommodate multiple user sessions, which can be mirrored data relay or storage sessions. Multiple combinations and examples of the above scenarios can thus occur simultaneously or separately in a suitable environment. To make a specific combination, you need to include more processors, disks, memory, and so on.

These various means and techniques can also be used in one to many mirroring systems or many to one mirroring systems in accordance with the present invention. In the same way, discussions of the means and techniques associated with packets can be made with respect to IP, Ethernet, Token Ring, or other packetized data environments, where other supported environments can write data streams instead of using packets. Will understand.

The steps mentioned above and elsewhere in this specification may be performed in various orders and / or concurrently except when the result of one step is input to another step. For example, steps 1034, 1036, and 1038 that are connected to each other may be performed in various orders and / or concurrently, but many of the operations of test step 1310 are premised at least in part or in whole. have. In order to transmit data to the local mirroring unit during step 1312, transmitting data over the link 206 or to the local mirror 230 during step 1314 needs to be preceded. On the other hand, transmission step 1316 may be performed by executing transmission step 1314 (or by using a private dedicated link 206) if transmitting to a remote mirroring unit without a server. The steps shown may be omitted, whether or not described as optional in the present description, unless otherwise indicated in the claims. The above-described steps may be repeated, combined, or otherwise named.

15, now and directly related technologies, additional tools and techniques to be used (individually or in various combinations) in accordance with an embodiment of the present invention, namely local-remote role shift, hot standby server state implementation. Some alternate buffer content and buffering schemes, transactionalization, many-to-one mirroring (as already described in Figures 5-10), the identification of frequently accessed data, the use of a second server in an unauthorized manner, and the like are discussed.

Role shift

If the main server, such as server 200, becomes inoperative and change data flows completely to the remote site, mirroring units such as units 204 and 208 switch roles, and remote servers such as server 300 on the WAN. For example, it allows disaster recovery to network colleagues. The assignee of Miralink's first US Pat. No. 5,537,533 discussed a replacement network server that is continuously valid and remotely mirrored. However, the validity of role shifts has not been explicitly discussed. In role shift, the entire mirroring unit architecture is inverted in effect. If any event requires disaster recovery, if the local and remote mirroring units survive, the original remote side will appear to be the local side after the local-remote role shift, and the data change is mirrored back to the existing local, now remote side.

In one embodiment, role change step 1506 is implemented as follows. First, "box" pairs (mirror units, such as units 204 and 208) are ideally configured to facilitate motion conversion. Next, the kernel module that handles SCSI emulation is activated in the local box and deactivated in the remote box. The “medium not ready” (hereinafter also referred to as media inoperable) feature to be discussed below substantially comes from this software state. If the local box has handed over all of its change data to the remote box, the user can order a role change. This disables the local max mirroring and enables the remote SCSI emulation layer so that the remote server can now command the remote mirroring unit to be installed. Thus, mirroring units alternate roles at each site, and the participation of servers affects them. The current role of the mirroring unit can be indicated internally by bit flags or other variables.

The physical disk used as the transmission buffer of the mirroring unit operating in the local role is used as the reception buffer when the mirroring unit alternates 1506 roles and starts operation in the remote role. In a local mirroring unit, such as unit 204, this disk is a transmit buffer that stores change data for the Journey link 206. In the remote mirroring unit, this same disk is a receive buffer which holds the received 1504 change data until it is delivered to the remote side mirror buffer disk or other inactive magnetic field device. Confirmation level and propagation time latency may be programmable in some embodiments.

From medium unavailable to secondary server

Using the "media unavailable" state (1508), the secondary server is in "hot" standby mode. Otherwise, there will be no need to use the secondary server after the remote mirroring unit 308 is online to enable the secondary server to signal the SCSI chain for the presence of the remote mirroring unit 308. During step 1508, the SCSI emulation layer of the remote mirroring unit responds to requests for data characteristics such as data size and data validity from the remote server 300, but access to the data content of the remote server 300 is denied. . This limited response query to server 300 is provided by unit 308 using a standard SCSI response format.

Alternatively, the secondary server 300 can be brought without the connected remote mirroring unit 308. As a result, after a failure, when the cable is connected, the SCSI probe of the device chain must detect the new hardware. Server 300 then mounts device 308. Conversely, with a preferred approach using the 1508 medium inoperable mode, the volume 308 remains powered and detected but not mounted until failover is required.

Circular buffer

Two additional modes of operation extend the usefulness of circular data queues in a "buffer" by allowing a "mismatched" mirror mode (i.e., no longer a complete time delay mirror) that can recover at a given time and / or bandwidth. Queues are also called “scalable intelligent buffers”, “circular buffer queues”, or “CBQs.” They use disk space as a FIFO (First In First Out) structure in normal mode and can reach high levels. Instead of storing the actual change data, the mirroring unit stores the change block Logical Block Numbers (LBNs) (1510) at a high water level (1510), which reduces CBQ (128 LBN [4 each). Bytes] versus one change data block [each 512 bytes], thereby reducing the rate at which the CBQ is filled, indicating that more time is given to the recovery of the Journey link 206. If the knee link 206 is kept down enough to completely fill the CBQ, a full fun is required, but since the system only needs to recover changed blocks once, CBQ is a virtual file allocation table (FAT) or A similar block (i.e. cluster or sector) allocation scheme can be entered, storing checksums or cyclic redunduncy check values as CBQs for each block. You will be notified by local mirroring units that need fun, and you will exchange CRC blocks, etc., with local mirroring units to determine which cluster of disks to send (for example). Unlike the initial mirror, which assumes that the data is 100% different between the rings, more than 90% of the hard drives are unchanged. It may not be necessary to send to ch 206.

SCSI snoop buffering

In some embodiments, an expandable intelligent buffer (eg, circular buffer queue) in normal mode stores the change block until the mirroring unit reaches a threshold that stores the change LBN instead of the actual change data (1510). In a variant using "SCSI snoop buffering", the data mirroring system buffers the actual SCSI commands without truncating the block data and buffers these SCSI commands. This is accomplished as follows, in another embodiment of step 1512 shown in FIG. 15, one or more specific operations, denoted 1512 in common herein, may be omitted or included.

The target adapter of the mirroring device 204 listens to the SCSI bus in a passive manner. “Passive” here does not mean that the physical device 204 is not electrically connected to the bus, but rather records 1512 what is seen on the bus. The target adapter is substantially similar, but will use physical hardware not intended for use with a SCSI analyzer. The SCSI analyzer is an analytical tool that allows the user to monitor the activity of the SCSI bus without substantially interfering with it. The data 1512 collected from the SCSI bus by the target adapter of the present invention is then interpreted for activity in or out of a particular target or actual "target" of the SCSI bus. This data includes the hermetic SCSI command set shown at 1412 of the SCSI bus.

Commands that meet the 1512 filter criteria, i.e., commands that only include the associated participating SCSI buses, can then be queued and observed using the appropriate buffering algorithm. 1512 data collected from the SCSI bus need not be analyzed or interpreted beyond acknowledging the command or responding from a particular participant on the bus. However, operation 1512 may be taken to (a) divide the readability request from the host controller on the bus (b) from the writable command from the host controller on the bus. By buffering the writable command 1512, the buffer will only contain transactions that involve changing data, or changing the state of the target participant on the SCSI bus.

The buffered SCSI command data is passed 1502 to a second mirroring unit 208, 308, etc. across a communication link, such as the jonny link 206. After being received (1504), the command is “replayed” by repeating on a participant that is the same or similar to the second physically separated SCSI bus (1014), which starts in the same state as its counterpart on the first bus. In this way the replication target participant on the second SCSI bus will be in the same state and will contain the same data as the original target at the same time as the command is read from the original SCSI bus. A bus other than the SCSI bus may be used for command receipt and playback and other aspects of the present invention.

When implementing the present mirroring system, it is important to observe undesirable fine interactions between the read request and the write request. This is especially true if the observed SCSI bus participant is invisible, but is stealthily maintaining an internal state that changes the behavior for subsequent read operations following the previous write operation.

In addition, errors reported from participants of the monitored SCSI bus from which commands are received need to be handled consistently on the second SCSI bus, but will not necessarily cause the same error. In addition, an error condition that occurs on the second SCSI bus makes the second SCSI bus inconsistent with the first SCSI bus.

Temporal Transactioning

Temporary transactional 1515 provides transaction filesystem functionality using mirroring unit 204, 208, etc. buffers. Note that other embodiments of step 1516 may include or omit one or more specific activities, commonly referred to herein as 1516. File opening and closing, and file operation timestamps will be tracked to support regression 1516 of file system operations that do not support transactions with operating system agents and / or kernel wedges.

Here, a "kernel wedge" is a binary patch or source code patch that is fixed to binary code or source code that exists to modify the operating system. This differs from device drivers or agents because kernel wedge insertion occurs in operating systems that are not specifically designed to additionally link or insert software. By inserting code into the operating system at the point where these actions occur with file opening and closing, actions based on these events can be taken.

This approach can be seen as a mixture of mirroring and replication, where replication is copying files when they are close and mirroring is copying open files when they are written. This approach attaches a timestamp or other marker to the mirrored data based on when the recording file is opened and closed. Thus, all changes to the file after being opened by the program are related to the open / close cycle and changes after the file is opened again will not be related to the current cycle.

Due to lack of space or other factors, it may be difficult to remember 1516 a particular block associated with a file when an open / close operation is performed, but easily remember 1515 the exact time at which a particular open / close event occurs. The exact time the block enters the buffer can be easily remembered (1516). Thus, after a time, the system administrator can network 1516 the open / close log provided by the wedge and selectively remove modified-data blocks that match a particular period.

It should be noted that this approach provides a relatively small advantage when used only in applications that open files for long periods of time and write data to files for long periods of time, such as in a database. However, this approach is quite useful for protecting the file system or recovering accidentally overwritten word processor files (1516) as these operations occur as soon as possible within a short time. File system changes may be properly detected (1516) at the correct point in time when they occur, such as in a file save operation from a word processor. Next, the data change mirroring operation corresponding to this time can be confirmed (1516), and the selected data change operation can be edited (1516) from the stream of the data change operation performing mirroring.

Transactioning 1516 may be accomplished by a remote system administrator or other program that may maintain changes in the data log in the buffer (1516) and roll back the changes for a period of time. The remote system manager resides on a remote data mirroring unit, such as unit 208, and receives data change information from local data mirroring unit 204 over communication link 206 (1504, 1516).

In some embodiments, the system has mirror disks and buffer disks on the local and remote sides, but the buffer disks on the remote side, such as buffer 310, need no longer exist on the remote side for any reason and are not local. As long as it is not actually used and the remote / local role is replaced (1506), the remotely mirrored data can be recovered from where it was mirrored. Thus, the remote buffer disk may be used to maintain a transaction log (1516).

The log (s) can be organized in a structure similar to a transmission queue, in which data blocks are saved 1516, and information about them (LBN and timestamps) is also saved in order. Instead of writing data immediately to disk, the present invention stores the data in a buffer for a time determined by buffer space availability and / or manager preference (1516). When that time has passed, data is removed from the buffer (1516) and written to the mirror image (1500). At this point, the administrator does not have the option to cancel the record. If the remote unit 208 needs to be a local unit 204, the entire remote buffer 310 may be replaced by a RAID unit 312, such as before the same buffer space 310 is used for the data transfer 1500. Need to be charged to disk.

More generally, a buffer with time stamp information may be used to effectively cancel (1516) events that have already occurred on the mirrored server 200 and the buffer 310 of the remote system receiving the mirrored data, but, for example, RAID The buffer 310 cannot be allocated for the mirror image on the unit 312. The canceling operation is performed by the administrator only by removing the problem block from the queue on the remote side using a management utility.

Alternative buffering technique

Other buffering techniques can be used to save buffer space and time compared to a simple circular queue in some mirroring units 204. Assume that blocks are written to the local mirror 230 as they are received, and that the LBN numbers are saved only by the ordered queue. As used herein, “sorted queue” refers to any queue, list, FIFO, table, or other set of one or more data structures that allow items to be recovered in the same order according to the structure described above. In particular, a circular queue is an example of an ordered queue.

If a mirrored block is written over a block that is already in the queue and not copied 1302 to the remote site, the pre-existing block is the same way as performed in the previously described embodiment (e.g., the block itself is placed in the swap space). During storage, only pointers to blocks are placed in the buffer space). Current alternative buffering techniques ensure that the entire buffer is in "compact mode" and is still stable at the same time. Only changes in the change can be buffered.

"Compact mode" and "normal mode" indicate the buffering mode. Compact mode implements a "do your best" strategy with play like buffer fullness. Normal mode is a commonly used buffering approach until a manager-defined or other free buffer space threshold is reached. Metaphorically, Threshold is sometimes called the "high-water mark" because if the water level is too high, you have to do something about it. Once the threshold reaches the buffering operation in compact mode, data integration can no longer be guaranteed in all cases, because only the LBN and the modified LBN can be stored, not the LBN and data. Data is typically written to the local mirror 230. When the LBN is read from the queue, the data to be transmitted is read from the local mirror 230. In many cases this is well done and all data is mirrored.

In some cases, however, the file is recorded, further modified and rewritten. Both of these changes are reflected in the queue, but if the first change is removed from the queue, the data to be transmitted is actually data from the second (or subsequent) change, so that this is the time before the remote mirror on the disk 310/312. Will appear. This is a significant problem if the user mirrors the file system rather than individual word processor files, since file system objects are often overwritten. However, this is a "might work some of the time" technique, which still provides some protection and is better than simply operating from a buffer.

Current alternative buffering techniques, which improve this approach, operate in much the same way. However, on subsequent writes to a given data block, the block on local mirror 230 is copied and stored somewhere other than the buffer, so that the LBN number in the buffer will point to correction data instead of subsequent data. It is impossible to insert such data at the tail of the queue; In general, too many queue elements need to be moved to make room. However, each entry for a particular LBN can be changed as appropriate to reference the data block at another location on the system. For example, the second storage area can be used by the local mirroring unit 204 to maintain this block.

The advantage of an alternative buffering technique is that only one operation is needed most of the time. Read / write / write operations need to occur from time to time, that is, reading blocks from local mirror 230, writing them to temporary storage, updating LBN entries in queues for points to blocks in temporary storage instead of in mirror, and transferring The new block is written to the mirror 230 in which the data copy is stored, and the LBN entry of the new block is added to the queue.

Remote many-to-one mirroring

This innovation includes the technology disclosed herein, which is further applied to provide a hardware / software platform in a many-to-one solution with a central backup site or service provider as disclosed. The local system generally operates as described above. The local mirroring unit 204 connects to the host server system 200 via the SCSI bus and then appears as a fixed disk drive used as part of a RAID-1 mirror, for example. The data is transmitted 1500 to the remote site via the local mirroring unit 204 transmission protocol from the local buffer 210 in an operating state as disclosed herein. The management interface supports a one-to-one view (from the perspective of the local mirroring system) between the local system and a remote many-to-one solution in a mirroring unit such as unit 508, 608, or 708.

The remote many-to-one solution can run the transport and buffer management software of multiple mirroring systems, i.e., multiple cases of software similar to the previously described remote mirroring unit 208, 308, 408 software (1520). ). However, in this embodiment, the kernel module is replaced with a user-space control module that emulates 1520 the kernel interface of the system described previously. A plurality of "virtual remote mirroring units" (herein referred to as "virtual systems" or "virtual 1.1 systems") may be hosted on one hardware platform within the server 300 or modified mirroring units 208, 308, 408. There is (1520). The hardware platform may be any high end server system capable of providing a commonly available Posix / Unix / SRV4 environment. Examples include, without limitation, Sun servers or IBM servers running Solaris / Linux or AIX / Linux, respectively.

To facilitate implementation of virtual system transport software that behaves as desired, the software may, for example, in a device comprising a local buffer, a remote buffer, a local mirror, a remote mirror, and a kernel, where data is transferred from device to device. It should be written in a modular fashion without making any assumptions about how it is done. Control of where data flows from and where to send it is done through a kernel interface that maintains state information about the conditions of mirror and user-induced state changes.

In some embodiments, the hardware platform includes a mirroring unit management layer to provide the local devices (for buffer devices, mirror devices, change mirror devices, and the like) with the mirroring unit management layer to provide the same functionality as the routing devices on the SAN storage. Run the SAN management software that interfaces. The management interface on the many-to-one system can be derived from the management interface on the mirroring unit already described using SNMP through the MIB extension and the world wide web-style GUI extension. Within the management layer, a one-to-one relationship is provided to the main (local) mirroring system while still allowing for the required state operation on the remote system. Within the management layer of an embodiment, a SAN management package is a model for a similar interface that a user can use to automate tasks such as setting checkpoints, making multiple copies of mirrored data, and changing mirrored devices. Can be used as.

Identify data elements that are frequently accessed without specific application knowledge

In this section and the next two sections, a block of data is an example of a “data element” and a disk sector is an example of a “storage element”. A "current set" can be considered as an extraction of a disk drive.

A common problem with fault-tolerant data systems is that if only a portion of the data storage operation set is completed before the application terminates, using the application does not employ a recovery method. Applications designed for fault tolerance typically have several ways of performing a set of data storage operations, but such operations are not considered valid until the last operation is performed, so if one of the operations does not continue, Is not considered valid. However, many applications are not designed like this.

One method of providing fault tolerance for an application that is not specifically designed for fault tolerance is application-specific information that includes detailed information about the actions that need to be performed and need to remember the state of the application outside of the application. To have. Complete transactions can be removed from the active data set unless they are performed through an external manager monitoring the application. However, this has a problem that the monitoring manager is sensitive to data changes outside the application itself by requesting specific information on the application's behavior.

The approach disclosed herein uses a monitoring manager that does not have the application specific information described above to identify frequently accessed data (1522). The administrator is responsible for the fact that one set of storage transactions by an application temporarily occurs in the associated cluster, which typically includes the operation of one set for the first group of neighboring data elements, and the storing operation comprises It occurs before and / or after the operation of one set for one group, and the storage operation is assumed to occur in or near a second group of adjacent data elements that are located somewhere other than the first group and are common for different transactions ( 1522). These common elements are referred to herein as "state blocks."

As an example, consider a file system write operation. The data file is updated with one or more sets of operations that typically include one set of contiguous storage elements on a physical storage medium. An update is then made to the file system tables, which will be stored at different but consistent reference locations and within a limited number of storage element sets that are physically associated. Sectors or clusters holding user data in the file correspond to adjacent data elements in the first group, and sectors or clusters holding file system tables, bitmaps or similar file system data structures are adjacent data elements in the second group. Corresponds to.

Many applications support similar recording strategies. In order to improve write performance, certain operating systems may attempt to cluster cluster unrelated write operations into one write operation. As a result, the data file can be updated according to the operating system.

According to the present invention, as one method for identifying 1522, there is a transaction that stores the course of the save write operation between updates to this particular state block. A transaction includes all data written to a data file between two status block update information. State block identification can be done by training the application in all normal operating ranges and by remembering how often and in what order the storage operations of 1522 are recorded. Neural networks, statistical analysis or other familiar techniques and tools can be used to extract the state block identification from the log of results. Over time, the log set indicates which storage elements are accessed and written much more than others and should therefore consider (1522) status blocks. This method cannot be applied to the application under discussion unless a statistically relevant pattern is clearly found. This method is not necessary for every storage-utilizing application.

If the method is properly employed, if the application fails and cannot be recovered, recovery can be supported by un-commiting 1524 contiguous data blocks, until the application recovers its state. Uncommitted 1524 status block updates are written between status block updates. In some form of nonvolatile storage, data elements are rewritten between state block updates to support the uncommitted nature of this invention. Alternatively, the present invention may perform a buffer storage operation before storing these on disk, and releases the buffer space in question after detecting and processing the next set of state block storage operations. Read operations must be read from the buffered storage, not from the associated copy. A table may be maintained to indicate the location of certain data elements in the buffer or committed storage.

Resynchronize unauthorized secondary data from the primary data volume

The present invention also uses an auxiliary data volume as the primary data volume for a period of time and then unlicensed auxiliary data volume such as remote mirror disk subsystem 312 or 614 from the primary data volume such as local mirror 210 for disaster recovery. Tools and techniques for resynchronizing

In normal operation, data elements are written to the primary data volume and then written to the auxiliary data volume by some means, such as mirroring units 204 and 208. Data on the primary data volume is considered to be authorized and is referenced when data elements need to be accessed. If the primary data volume has failed non-disruptively (for example, when it is powered off or temporarily isolated from the using application of the stored data element), the using application is moved to the auxiliary data volume for storing new data elements and reading data elements. Can be switched. While the primary volume is unavailable, it maintains a list (or table, or other data structure) indicating data element change in the secondary volume (1526). This list resynchronizes the contents of the primary volume with the contents of the secondary data volume when the primary volume becomes available (1526). Resynchronization 1526 process reads the corresponding data element from the primary data volume and writes it to the secondary data volume.

In such a scenario a change is made to the auxiliary data volume that is supposed to be disallowed and rewritten normally by resynchronization 1526. This is because, for example, it is a unique case for a using application.

Where appropriate, the present invention provides a simple method for reestablishing a master-subsidiary relationship between two data volumes. This resynchronization 1526 is different from role inversion 1506 (in role inversion the secondary data volume becomes the primary grant volume while in resynchronization 1526 the primary data volume exists as authorized).

Keep ordered queues and current copies on the same physical storage system

As discussed elsewhere herein, in some embodiments the data element record may be read in the reverse order by being stored by mirroring unit 204 in a sequential queue of the order in which it is received. In some embodiments, a set of data storage elements is defined as a “current copy,” and the data elements can all be read backwards from the current copy (1528). A new storage operation for a given data element of the storage device will update the data element in a current copy (1528), and the data element may use 1528 to restore the initial system state.

This is managed by maintaining 1528 a storage element location table (or other data structure) for the current copy. The table identifies the address of the most recent data element for a given storage element in the current copy. As the read request is processed, data elements are found in table 1528 and the table is read from the sequential queue at the point referenced. The sequential read request is handled (1528) by reading from a known location in the sequential queue in a queue forward manner.

In this way, there is no compelling reason to keep two copies of the same data element physically divided. The present invention does not require writing the same data element twice to the operating system to implement a physically partitioned system. Other embodiments of step 1528 may include or omit one or more specific actions jointly indicated by reference numeral 1528 herein.

As the physical operating system is charged with sequential queue data, the oldest sequential queue element is terminated (1528) and the storage will be empty for the new sequential queue element. If the oldest queued elements in the current set are terminated, they can be copied to the secondary storage device (1528) and the sequential set is updated (1528) to refer to these new locations. Although this is an application-on-demand, whether in common or common scenarios, in many scenarios this aspect of the invention 1528 tends to reduce the number of write operations that need to maintain a sequential queue of current sets and data element sets.

As a result of maintaining the sequential queue, the previous current set is available for reconstruction 1528. The previous current set selects a point in time when the sequential queue is to be a new current set (1528), scans the reference table for reference to the elements of the new sequential queue than at the selected time point (1528), and retrieves the correct portion of the current set Update the criteria table referring to the old sequential queue elements that are mentioned (1528).

In many situations, a performance penalty will be made for the read operation by these embodiments of 1528 of the present invention, since in some situations it will not be done for consecutive storage elements. Preferably, for example, if the sequential queue is implemented as a linear array for the storage elements of the storage system, the storage operations must be efficient in any order because there is always a storage operation for consecutive storage elements in the sequential rules configuration.

Storage media layout, signal

Articles of manufacture within the scope of the present invention include computer readable storage media in combination with the specific physical configuration of the substrate of the computer readable storage media. Substrate configuration represents data and instructions that allow a computer to be operated in a specific and defined way as described herein. Suitable storage devices include floppy disks, hard disks, tapes, CD-ROMs, RAM, flash memory, and other media readable by one or more computers. Each medium reliably implements programs, functions, and / or instructions executable by a machine to install and / or use a method of performing any or all of the processes shown in FIG. 13 and the systems shown in FIGS. A method of mirroring method that is substantially flexible, as described herein, is performed, including, without limitation. The invention also provides novel signals for use in or by such programs. This signal may be implemented in "wiring", RAM, disk or other storage medium or data carrier.

More information

Further recognition and detailed information are provided below to assist people and businesses in understanding and properly implementing the invention. This description is given on the assumption that any of the kind of embodiment (method, system, configuration storage medium) also applies to other embodiments, unless clearly indicated otherwise.

Embodiment improved by inventor

Many other solutions to the data protection problem of tape backup, local clustering, copying, shadowing, remote body channel expansion, etc., are directly connected and dependent on the host 200 operating system in some manner. This dependency can cause problems for the customer, which can be resolved by using the present invention. For example, if the software does not fully work with the current host operating system or an update to the operating system, the dependency on the dependent dedicated software can cause compatibility problems and bugs. Software solutions that rely on dedicated host mirroring software may present performance problems because they add extra work to the host. Dependent software solutions can be insecure. As disk volumes grow and software and operating systems become more complex, the problem of approaches requiring dependent software increases. Moreover, when the host 200 operating system stops, the solution that depends on the operating system also stops operating.

In contrast, in at least some embodiments, the present invention can reduce or avoid the aforementioned problems by having no software that is a load on the host computer (eg, local server 200). If the host operating system stops and subsequently operates the mirroring unit, the mirrored data is available because the mirroring unit executes its operating system. Unlike solutions that need to be substantially modified in their cores as disk volumes grow and software becomes more complex, the invention is more easily controlled. If a faster processor is available, simply use it in the mirroring unit as desired. If the disk size increases, insert a larger disk into the mirroring unit. If the rate of change of data exceeds the current capacity to write to disk, use a caching controller and add memory to the system. Other solutions require cooperation from the operating system manufacturer to integrate and work properly without bugs. Since all operating systems support SCSI and, for example, fiber channels for the time being, this cooperation is not necessary to practice and use the invention.

If other solutions fail, the host 200 may take them because of the close interaction highlighted above. Since the present invention can operate regardless of the host 200, even if it fails, it does not seriously affect the host computer. Conventional disk mirroring was originally designed for local fault tolerance. Two disks are written in parallel so that the computer continues to run even if one disk fails. The failed disk is removed from the operating system in the background. Operating systems and computers often continue to operate. Since the original mirroring unit is similar to a SCSI disk and can be mounted as a mirroring disk, it provides similar advantages. Also, if the mirroring unit expires, it is detached. For example, if the operating system or other software in the mirroring unit fails, the mirroring unit stops disk emulation. As a result, the operating system on the host 200 no longer recognizes the mirroring unit. In response, the operating system on host 200 simply detaches mirroring unit 204 and continues to operate.

At least some previous mirroring system implementations are used for one disk IDE buffer. Even in the case of spoofing, these smart buffers cannot keep fast SCSI RAID units at high speed with hardware stripping. The most critical data sent remotely is left on a single disk that does not cause fault tolerance at the smart buffer level. In contrast, according to the present invention, both local and remote mirroring units can be mirrors and one disk buffer can perform hardware RAID striping across multiple disks corresponding to a fault tolerance. This provides the ability to maintain a new high speed storage subsystem and better fault tolerance on the server. In case of an individual disk failure in the server 200, the volume or mirroring unit disks 210 and 310 also reduce the risk of loss of buffer data.

Limited data entry capabilities in the prior art make it very difficult to describe a new technique for obtaining market acquisitions. For example, there is no storage access network ("SAN") or network attach storage ("NAS") support in at least some prior art. Requiring a standard remote server, such as server 300, makes it difficult or impossible to back up and mirror the SAN and NAS disk subsystems that are becoming increasingly common. However, all these subsystems can do local mirrors via Ethernet, Fibri Channel, and / or SCSI. The mirroring unit of the present invention can accommodate a number of input types including SCSI, Ethernet, and Fibre Channel inputs.

The present invention also supports a larger storage subsystem. Many previous fault tolerance solutions were designed in environments where six gigabyte storage volumes were considered very large. As storage costs drop, disk subsystems are growing in size very rapidly. It is common for a server to have a capacity of 100 gigabytes. The present invention accommodates some of this huge capacity by handling synchronization to the host server 200 in the background, ie the mirroring unit. Sharing this task from the host server to the mirroring unit may not significantly reduce the performance of the true mirror of the primary host server 200. In contrast, mirroring solutions that require a local server to handle alternative “clustering” and / or synchronization required for the mirror can both slow or destroy the primary server.

At least some previous execution of mirroring requires the local server to intervene over the telephony link, even if there are many implementations to avoid resynchronization of the mirrored disks, even if the local buffer cannot support the entire local volume. Remirring takes several days to slow down the main / main / host server 200 and bring it to a stopped state. Remirring is therefore usually done only on weekends when there are few users and the network can run slowly. However, as the disk subsystem grows, it can no longer be accommodated. The present invention supports non-volatile storage that is large enough to maintain the entire volume being remotely mirrored at the local mirroring unit 204 as well as at the remote location. This allows the local mirroring unit 204 to check the entire local disk storage volume in advance in a localized smart buffer and to clearly do the tasks associated with the mirror in the "background" from the server 200.

In at least some prior art, limiting the T1 maximum output rate locally or remotely slows remirror even if a frame relay network, ATM and / or VSAT network is available. In contrast, the present invention can improve the performance and data deployment more efficiently because the I / O pipe capacity can be made larger and the mirroring can be faster. When remotely stored mirrored data becomes unavailable, data stored at unavailable sites can be moved to other facilities at high speed using a high speed personal data network. Such data networks typically support up to OC48 rates (2.488-gigabyte per second). This example may require a customer to mirror their data to Chicago and use facilities to retrieve from New York. This kind of need is much more common than it is originally realized.

Native off-site server products fail to provide an open application programmer interface (“API”). Only closed proprietary hardware (MiraLink's) and closed proprietary software (Vinca's) are recorded exclusively instead. If an enterprise customer needs more than a product scope, changing or modifying an order is not easy. In contrast, in the present invention, by allowing open APIs, adjustments are made from the user space process to designate specific customers and / or emerging markets. In particular, the present invention preferably provides one or more calls for reconfiguring the mirroring unit without interrupting the server 200 and also provides a call for rebooting the mirroring unit without interrupting the server 200.

Configuration data

System configuration data is preferably distributed such that configuration data can be recovered from one of the unit's peers if one of the mirroring units loses the configuration data. Basic configuration data, such as network information, is preferably stored in non-volatile storage (e.g., on disk or in battery-backed semiconductor memory), so that configuration data can still be restored from the peer mirroring unit even if the configuration data on the disk is lost. Can be.

The World Wide Web (WWW) interface preferably comprises at least the following configuration options or equivalent IP addresses (remote / local); Gateway (remote / local); Net mask (remote / local); Administrator password (public); Buffer size (local); Buffer high water mark (buffer filled to exceed capacity limit); Volume size (configurable to factory-designed hard masks); SCSI target logic unit number ("LUN"); And SNMP configuration (remote / local).

The SNMP configuration itself is preferably an add / delete SNMP monitoring host (remote / local); Event polling interval; Buffer filled past acceptable limits; Network connection failure; Buffer pool; Opting out of remote synchronization; Includes add / delete e-mail receipts.

The web interface preferably comprises at least the following state information whether the unit is remote or local: a buffer block; Block transmission; Block reception; Mirroring unit version; Mirroring unit serial number; Contains volume size. The web interface preferably provides an unmounted remote utility. The web interface preferably provides a log dump report. SNMP and SMTP traps typically have buffer fillable limits; Buffer pool; Network connection failure; Used for events such as remote sync leave.

The management tool provides the notification by e-mail, paging or other means. Notifications can be combined with real-time and / or automatic logs or automatically generated reports. The notification may be sent to the system administrator and / or vendor. Features of the web server are available in embodiments that implement the web server / mail server package as an interface. For example, a user can locally and remotely access and manage the monitoring unit. The authorization allows the user to access and manage the mirroring unit internally and / or from anywhere in the world. The mirroring unit notifies users (and mirroring unit vendors) of problems or serious events in the mirroring unit via e-mail as well as via SNMP. Custom scripts can be recorded for these emails so other users or groups of users are notified. Report outputs do not need to be static. If a customer requires a custom report for management and records the report multiple times, instead of copying the required information each month, the customer or a certified developer can use the HTML, JAVA, and / or other well-known tools and techniques to mirror the unit. You can create an email and send an email whenever you need it in the format you want.

Basic hardware

Typically, the system according to the invention comprises basic hardware such as a standard Pentium II, Pentium III, AMD K6-3 or AMD K7 class PC-compatible computer (indicating each owner). In various configurations the machine is preferably at least 64, 128, or 256 megabytes of RAM and has a rack-mounted case. Also preferably include one 100Mb Ethernet card, FDDI card and the like. As a disk interface, the machine preferably has a LgicSCSI card for disk emulation and an Adaptec 2940UW adapter for buffer and mirror control or a FreeBSD supported DPT brand RAID card. Caching including RAID or SCSI control caching, caching of volatile RAM in the mirroring unit, caching of nonvolatile RAM (eg, static RAM or battery-backup RAM) of the mirroring unit, and the like. Caching tools and techniques familiar to those skilled in the art may be suitably adapted for use in accordance with the present invention.

In some embodiments, if N is the size of the volume to be mirrored, local mirroring unit 204 includes a local mirror 230 having a storage capacity of at least N with a local mirror. In some embodiments, a disk system serving as local buffer 210 (with or without a local mirror) has a capacity of at least 6/5 N, i.e. 1.2 times N. The remote mirroring unit has at least one disk system and is at least size N for at least the remote mirror. In all scenarios, the local mirroring unit buffer 210 needs to have the same data capacity as the remote mirroring unit, includes a buffer and a hot-swappable RAID subsystem, and can accept local limiters. have.

Test suit

The test used to measure the performance of the system according to the invention can preferably be used to measure the relative performance and failure (pass / fail) tests covering critical functional specification conformance criteria. . If all questions have specific answers that match the test results correctly, then the test is passed. Fire testing can be used to determine delivery suitability.

The test preferably includes both local network configuration (where the Journey link 206 is within one local area network) and local and remote configuration (locally distanced from the local mirroring unit 204 and the remote mirroring unit). Must be passed. For example, the remote network configuration may consist of two sites connected with the T1 link 206 or an equal amount of public Internet band, such as the Journey link 206.

Analytical tests preferably use standard disk hardware test suites such as Bonnie (for Unix) or PC tools (for Windows NT and Novell clients). The test compares the performance of the native disk drive (specified model, size and characteristics) with the flexible mirroring unit 204. The performance outputs are later recorded for reference.

Preferably the following questions are asked, and any necessary corrections are made until the answer as indicated.

Is the mirroring unit 204 recognized by the host 200 operating system recognized as a disk with a correctly configured size? (Yes)

Can data be written and read without loss in the mirroring unit 24? (Yes)

Can host system 200 perform any data file operation on mirroring unit 204 without a 48 hour error? (Yes)

Is there a local mirroring unit 204 consisting of a 100 megabyte host volume and a remote network configuration that can successfully mirror data to the remote mirroring unit at a data rate of at least 300 megabytes per hour, preferably higher than FDDI? (Example) Note that the 300 megabyte per hour rate is approximately 50% or less of the maximum carry capacity of the T1 connection (T1 capacity is approximately 617 megabytes per hour).

Whether the local mirroring unit 204 can be completely rebooted without failing to operate in the normal manner without the attached host system 200, ie, can the host 200 continue to achieve its intended purpose without significant performance degradation? ? (Yes)

If the local mirroring unit 204 returns on the line, it is automatically initiated to transfer the data left on the local mirroring unit 204 queue via the network or other Journey link 206 (eg using TCP sockets) and Can the data be sent to the remote mirroring unit without loss? (Example) Note that this is confirmed by attaching a drive of the remote mirroring unit on the host system 200 before and after rebooting the local mirroring unit 204 while attaching to the host system 200. The remote mirror can be mounted after such an event without a significant need for file system recovery. The data must not be lost and must fit the application program that generates it. After physically mounting the remote mirror on the local host system 200, the host system 200 can mount the mirror and can the application program on the host 200 and its client use data continuously on the mirror? ? (Yes)

Is the mirroring system broken or insecure in response to input of inappropriate information, such as a bad remote IP address or an invalid SCSI ID (less than 0 or greater than 15)? (No) Can the user correct the information and do it normally without restarting the software and rebooting the mirroring unit? (E.) Can all software display the correct version number and copyright status? (Yes)

The local mirroring unit 204 continues in response to the mirroring operation or other disk I / O intensive operation being performed by the host system 200 while being disconnected from the network cable 206 for 30 minutes and preferably for a longer period of time. Does it work? (Example) Does the host operating system recognize the local mirroring unit as a disk with a correctly formed size? (Yes) Can data be read and written to the local mirroring unit 204 without loss? (Yes)

After the initial mirror was established, disconnect the network cable for 24 hours and perform periodic re-run checks. Does the host 200 operating system still recognize the local mirroring unit 204 as a disk with a correctly formed size? (Yes) Can data still be read and written to the local mirroring unit 204 without loss? (Yes)

Similarly, after the host system 200 causes the buffer 210 to overflow (eg, by re-mirroring multiple times), the local mirroring unit 204 is still appropriately available to the extent possible. Make sure it works. Does the host 200 operating system still recognize the local mirroring unit 204 as a disk with a correctly formed size? (Yes) Can data still be read and written to the local mirroring unit 204 without loss? (Example) Can the user restart the local mirroring unit 204 without having to reboot after stopping the en-queuing process? (Example) If the data is at least partially interesting more than once, can the user selectively flush some portion of the buffer, such as a broken mirror, without having to flush the full mirror? (Yes)

While the mirroring operation or other disk O / I intensive operation is being performed by the host system 200, disconnect the network cable or other Journey link 206 for 30 minutes. Can local mirroring unit 204 begin transmitting data from the queue to the remote mirroring unit after reestablishing the physical network connection? (Example) Valid statistics from the local mirroring unit 204 regarding the state of the buffer (e.g., full or not, number of blocks in the buffer, number of blocks transmitted from the buffer and received at the remote side) are used. Is it possible? (Yes)

Unplug the local mirroring unit 204 (UPS), shut down the host system 200, and then wait for power so that the local mirroring unit 204 does not operate. Restore power to local mirroring unit 204 and then restore power to host system 200. Is the host system working properly? (Example) Can the local mirroring unit 204 be completely rebooted without the connected host system 200 operating normally? (Example) When the local mirroring unit 204 is restored online, the data remaining in the buffer 210 of the local mirroring unit 204 may automatically start transmission through the network or another jog link 206 without data loss. Is there? (Example) Of these remote mirroring unit mounting tests, note that the last two tests should be performed before and after the simulated power failure. Are these passes? (Yes)

Also, are all previous tests successful using a host capacity size of 200 gigabytes? (Yes)

Can the remote mirroring unit be disabled and this remote mirror can be mounted by a standby server running the same offending system as the primary host system 200? (Yes)

Next, does the remote host behave normally and without adversely affecting its performance? (Example) Note that the operation of the previous two tests is supported by having a remote backup host and its remote mirror disk subsystem 312 or 614 connected to the same SCSI chain as the Rimto mirroring unit.

summary

The present invention provides tools and techniques for local and / or remote data mirroring. In particular, a computer system for remote data mirroring in accordance with the present invention includes one or more flexible mirroring features. In addition, systems for local mirroring (eg, where the source and destination are within 10 miles) can also include this flexible mirroring feature.

For example, the system can be characterized as having a serverless destination. That is, the system of this embodiment is a destination remote mirroring unit 208, 408, 508, 608 through the local mirroring unit 204 from the source local server 200 without using a remote server connected to the remote mirroring unit. Or 708 to mirror the data.

The system may also be characterized as non-invasive in that software designed specifically for remote data mirroring does not need to be installed on the local server 200. Likewise, such software need not be installed on the secondary server 300 in the system including the server 300. Instead, each mirroring unit executes an operating system and one or more remote data mirroring application programs (including threads, processes, tasks, and the like). For example, rather than the server (s) buffer data to be mirrored, a mirroring unit is created, monitors the connection over the Journey link 206, and transmits and receives mirrored data over the Journey link 206, thus the server (s) Alleviate these tasks. Similarly, the system may be characterized by a disk emulation in which the system mirrors data from the local server 200 to the local mirroring unit 204 via a standard storage subsystem bus. Suitable standard storage subsystem buses include SCSI, Fiber Channel, USB, and other general purpose buses. These buses have also been referred to herein as "connections" to the local mirroring unit 204.

The system may be characterized by TCP Journey line characteristics and / or Ethernet Journey line characteristics. For example, in one case, the system mirrors data from the local server 200 through the local mirroring unit 204, which operates as a TCP client via the journey line 206, and the remote mirroring unit. 208, 308, 408, 508, 608, or 708 acts as a TCP server. More generally, the low line characteristic is that there is no high bandwidth low latency requirement imposed by SCSI, original offsite server serial connection, SAN connection, etc. in the connection between the local mirroring unit 204 and the remote mirroring unit. Is pointing.

The system may also be characterized by variety. That is, the system can provide many-to-one mirroring from two or more local (primary) servers 200 to a single remote mirroring unit 208, 308, 408, 508, 608, or 708. Then, the data mirroring system of the remote mirroring unit nonvolatile storage includes one disk partition for each primary mirroring unit, one external hard disk 614 for each server 200, and one for each server 200. RAID unit 312, or any combination thereof, each disk partition holding mirroring data for each server 200. The various primary (local) servers 200 may all use the same operating system or may use any combination of other operating systems. In some cases, the destination nonvolatile storage is large enough to hold the combined current nonvolatile data of all primary servers 200. In another variety, the system may provide one-to-many mirroring from a given local (primary) server 200 to two or more remote mirroring units 208, 308, 408, 508, 608, or 708. .

The present invention also provides a method of installing a flexible mirroring unit, a method of using the unit, and a method of performing both. For example, a method for facilitating flexible data mirroring includes at least two steps in the installation step group 1300. Another method of flexible data mirroring includes one or more transmission steps 1302.

One of the installation steps connects the local server 200 to the local mirroring unit 204 using the standard storage subsystem bus 202 so that the local mirroring unit 204 is communicating over the link 202. Enabling emulation of the disk subsystem. Step 1306 includes connecting the local mirroring unit 204 to the Journey Link 206 to transmit data by at least one of an Ethernet connection and a TCP connection. Step 1308 is to connect the remote mirroring unit 208, 308, 408, 508, 608, or 708 to the Journey Link 206 by at least one of an Ethernet connection and a TCP connection to receive the transmitted data. It includes. The test step 1310 tests the at least one mirroring unit 204, 208, 308, 408, 508, 608, or 608 after at least one of the above connection steps is at least partially completed.

One of the transmitting steps 1302 transfers data from the local server 200 to the local mirroring unit 204 via the standard storage subsystem bus 202, while the local mirroring unit 204 sends the disk subsystem. Emulating step 1312. Step 1314 transfers data from the local mirroring unit 204 to the remote mirroring unit 208, 308, 408, 508, 608, or 708 over the jorn link 206. Step 1316 (which may perform the same data transfer as step 1314) is performed when the remote mirroring unit is a serverless, i.e., when the remote mirroring unit is not connected to the secondary server 300. From 204 to the remote mirroring unit 208, 308, 408, 508, 608, or 708 over the journey link 206.

In the above and other embodiments, the present invention provides a role shift (1506), a hot standby server implementation (1508), various buffering and other storage schemes (1510, 1518, 1528), command capture ( 1512), and playback on SCSI or other buses (1514), execution of multiple remote heading unit software (1520) on a single hardware platform, and storage of certain applications to support application state recovery (1524). It may have additional features regarding the identification of frequently accessed data 1522 based on observation over time, and the use of an unauthorized secondary server 1526, rather than more advanced knowledge of operation.

Embodiments of the present invention mask the low link bandwidth of the Journey Link 206 delay time to the remote mirroring unit, thereby enabling long-distance off-mirror previously in which mirroring is not feasible even with a dedicated fiber. Benefits include facilitating site mirroring, facilitating mirroring over low cost network connections, and the like. These low cost connections can be used even if they have enough bandwidth to support the average disk data change rate rather than the peak rate. The embodiments can be used not only for backup and recovery, but also for high availability primary storage systems. In a remote many-to-one embodiment, a kernel module, or software interface to buffers and SCSI or other transport protocols, is a more general user-space that emulates the interface of a system without the need for an actual SCSI or other transport protocol processing layer. Can be replaced with a (user-space) control module. The devices may include, for example, a local buffer, a remote buffer, a local mirror, a remote mirror, and a SCSI or other transport protocol layer. The hardware platform running the SAN operating software may be centralized.

Particular embodiments (methods, storage media, and systems) of the present invention are specifically illustrated and described herein. In order to avoid unnecessary repetition, the concept and detailed description applicable to one embodiment are hardly particularly described in the other embodiments. However, even if mentioned otherwise, the description herein of specific embodiments of the present invention may be extended to other embodiments. For example, what is discussed about the system of the present invention also relates to the method, and vice versa, and the description of the method of the present invention relates to the corresponding storage medium and vice versa.

As used herein, terms such as "a" or "the" and titles of items such as "mirror unit" generally include one or more indicated items. The invention may be embodied in other specific forms without departing from its essential characteristics. The above-described embodiments are illustrative only and not limiting. Headings are for convenience only. The scope of the invention is defined by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (44)

In a data mirroring method, Mirroring the data; And Performing local-remote role reversal on mirroring units Data mirroring method comprising a. A computer storage medium configured to perform a data mirroring method, comprising: The data mirroring method Mirroring the data; And Performing a local-remote role shift for the mirroring units Computer storage media comprising a. In a data mirroring system, At least two mirroring units, each of the mirroring units comprising means for performing a local-remote role shift of the mirroring units in the system Data mirroring system comprising a. In the data mirroring method, Mirroring the data; And Rather than storing the changed data in the buffer, storing the changed logical block number in the buffer Data mirroring method comprising a. The method of claim 4, wherein Changing the logical block number of a predetermined position of the buffer so as to refer to the data of the second position rather than to the data of the first position when the block corresponding to the logical block number is overwritten. The first position holds data for the block before the block is overwritten, and the second position holds data for the block after the block is overwritten. Data mirroring method further comprising. A computer storage medium configured to perform a data mirroring method, comprising: The method is Mirroring the data; And Rather than storing the changed data in a circular buffer, storing the changed logical block number in the circular buffer Computer storage media comprising a. The method of claim 6, The data mirroring method Changing the logical block number of the predetermined position of the buffer to refer to the data of the second position rather than to the data of the first position when the block corresponding to the logical block number is overwritten; Data is stored for the block before the block is overwritten at position 1, and data for the block after the block is overwritten at the second position. Computer storage media further comprising. In the mirroring unit, buffer; And Means for storing a changed logical block number in the buffer rather than storing changed data in the buffer Mirroring unit comprising a. The method of claim 8, And said storage means comprises a virtual block allocation structure. The method of claim 9, The virtual block allocation structure includes a block checksum rather than block data. The method of claim 10, And the mirroring unit transmits block checksums to another mirroring unit via the Journey Link, rather than transmitting block data in the resynchronization period of the two mirroring units via the Journey link. In a method of putting a secondary server in hot stand-by mode, Booting the secondary server; And By providing the secondary server with a "media not ready" signal from the mirroring unit acting as the secondary, the emulation layer responds to requests from the secondary server regarding the size and availability of the data. Reply, but denying access of the secondary server to data content until the role of the mirroring unit is changed How to include. The method of claim 12, Changing the role of each mirroring unit by performing a local-remote role shift between the mirroring unit and another mirroring unit in the data mirroring system How to include more. A computer storage medium configured to perform a method for placing a secondary server in hot standby mode, the computer storage medium comprising: The method is Receiving a query signal from the secondary server; And By providing a response signal to the secondary server, the emulation layer of the mirroring unit provides at least information about the size of the mirroring unit data but rejects the secondary server's access to mirroring unit data content from the secondary server. Responding to requests Computer storage media comprising a. The method of claim 14, The method is Performing a local-remote role shift between the mirroring unit and another mirroring unit in a data mirroring system Computer storage media further comprising. In the mirroring unit, Data storage media; And Emulation layer Including, And said emulation layer comprises means for responding to a request from a secondary server by providing characteristics of data stored on said storage medium and denying access of said secondary server to content of said data. In the data mirroring method, Mirroring the data; Snooping the bus; And Buffering at least one command obtained in the snooping step Data mirroring method comprising a. The method of claim 17, Distinguishing a read attribute command from a write attribute command, wherein the read attribute command is a request from the host controller on the snooped bus of the read attribute, and the write attribute command is a command from the host controller on the bus of the write attribute Im- More, The buffering step buffers a write attribute command. The method of claim 17, Transmitting the buffered command from the first mirroring unit to the second mirroring unit via the communication link Data mirroring method further comprising. The method of claim 17, Replaying from a second mirroring unit command buffered by the first mirroring unit Data mirroring method further comprising. A computer storage medium configured to perform a data mirroring method, comprising: The method is Mirroring the data; Snooping the SCSI bus; And Buffering at least one SCSI command obtained in the snooping step Computer storage media comprising a. The method of claim 21, And wherein said buffering buffers at least one write command. The method of claim 21, Reproducing from a second mirroring unit command buffered by the first mirroring unit Computer storage media further comprising. In a data mirroring system, SCSI bus; And At least one means for mirroring data, snooping the SCSI bus, and buffering SCSI commands obtained by snooping Data mirroring system comprising a. In the data mirroring method, Mirroring the data; And Providing transactional filesystem functionality using kernel wedges Data mirroring method comprising a. A computer storage medium configured to perform a data mirroring method, comprising: The method is Mirroring the data; And Steps to Provide Transaction Filesystem Functionality Using Kernel Wedges Computer storage media comprising a. In a data mirroring system, A source of data for mirroring; And Kernel wedges provide transactional filesystem functionality during data mirroring Data mirroring system comprising a. The method of claim 27, Local system; And Remote system Including, The remote system includes software for receiving data change information from the local system, maintains a data change log buffered in the remote system, and supports role change restoration at the request of an administrator. In the data mirroring method, Reading a block of data from the local mirror; Writing the data of one block into a temporary storage unit as a new block; Updating the logical block number input to the queue; Writing the new block to a mirror data collection; And Adding the logical block number input of the new block to the queue Data mirroring method comprising a. A computer storage medium configured to perform a data mirroring method, comprising: The method is Reading a block of data from the local mirror; Writing the data of one block into a temporary storage unit as a new block; Updating the logical block number input in the data structure; Writing the new block to a mirror data collection; And Adding a logical block number input of a new block to the data structure Computer storage media comprising a. In a data mirroring system, Read a block of data from the local mirror, write the block of data as a new block to the temporary storage, update the logical block number input in the data structure, write the new block to the mirror data collection, At least one means for adding a logical block number input of a new block to the data structure Data mirroring system comprising a. In the data storage management method, Reading data; And Providing a virtual remote mirror unit Data storage management method comprising a. A computer storage medium configured to perform a data storage management method, the method comprising: The method is Reading data; And Executing a plurality of virtual remote mirroring units on a single hardware platform Computer storage media comprising a. In a data mirroring system, At least two virtual remote mirroring units on a single hardware platform Data mirroring system comprising a. In the data storage management method, Reading data; Identifying frequently accessed data elements without prior specific application knowledge regarding the order and frequency of storage operations by the application. Data storage management method comprising a. A computer storage medium configured to perform a data storage management method, the method comprising: The method is Reading data; And Identifying data elements that are frequently accessed without specific application knowledge about the storage operation by the application Computer storage media comprising a. In the improved data storage management system, Means for identifying data elements that are frequently accessed without specific application knowledge Data storage management system comprising a. The method of claim 37, The means for identifying data elements that are frequently accessed without specific application knowledge is determined by the state of the application by floating state block updates written between un-committing contiguous data blocks and state block updates until the application state is restored. Data mirroring unit coordinated with means to help restore Data storage management system comprising a. In the data storage management method, Reading data; And Resynchronizing the unauthorized secondary data volume from the primary data volume after using the secondary data volume instead of the primary data volume Data storage management method comprising a. A computer storage medium configured to perform a data storage management method, the method comprising: The method is Reading data; And Resynchronizing an unauthorized secondary data volume from the primary data volume after using the secondary data volume instead of the primary data volume Computer storage media comprising a. In the improved data storage management system, Software that resynchronizes unauthorized secondary data volumes from the primary data volume after using the secondary data volume as the primary data volume Data storage management system comprising a. In the data storage management method, Reading data; And By maintaining an ordered queue of mirrored data elements and a current copy of the mirrored data elements in the same physical storage system, the same data element may be written to the storage system twice to implement a physically partitioned system. Steps not necessary Data storage management method comprising a. A computer storage medium configured to perform a data storage management method, the method comprising: The method is Reading data; And Maintaining an ordered queue of mirrored data elements and a current copy of the mirrored data elements on the same physical storage system. Computer storage media comprising a. In the improved data storage management system, Software that maintains an ordered queue of mirrored data elements and a current copy of the mirrored data elements on the same physical storage system. Data storage management system comprising a.