System and method for creating and maintaining secondary server sites

Disaster Recovery (DR) and High-Availability (HA) are a critical features required by many information technology systems. DR and HA may be accomplished with a remote secondary site that is kept synchronized with a primary site. To reduce the cost of maintaining a secondary site, the data may be split into two subsets wherein only a first subset of data is kept synchronized at the secondary site using a small bandwidth communication link. The second set of data, which is generally much larger, is periodically backed up at a network accessible back-up location. When a disaster occurs, the secondary site may access the most recent back-up of the second set of data. In a maintenance or limited failure situation, the secondary site can directly access the second data set at the primary site.

TECHNICAL FIELD

The present invention relates to the field of digital computer systems. In particular, but not by way of limitation, the present disclosure teaches techniques for creating and maintaining secondary server sites that may be used for a variety of purposes.

BACKGROUND

Computer systems have become an indispensable tool used in modern life. Nearly every business and government agency is now dependent upon computer systems for digital communication, project planning, document creation, information storage, transaction processing, inventory management, financial operations, and a large number of other mission critical services.

Although individual pieces of computer hardware and computer software can easily be replaced by an entity using computer systems by purchasing new computer equipment or computer software, the entity's accumulated stores of data cannot easily be replaced. The accumulated store of data is critical for allowing a business and government agency to continue operating. Thus, maintaining access to the accumulated data and protecting that accumulated data is one of the most critical parts of any modern information technology infrastructure for a business, government agency, or any other entity.

Two important features in providing data storage within an information technology infrastructure are high-availability (HA) data services and disaster recovery (DR) services. High-availability encompasses the task of ensuring that the stored data is available almost all of the time. Thus, even when system maintenance is being performed or when there are minor hardware, software, or network problems, a high availability data storage system will continue to provide access to stored data. Disaster recovery refers to the ability to restore a data storage system even when a major disaster strikes an information technology site such as a data center burning down.

An ideal data storage system will be able to provide both high availability and disaster recovery services. Products and services for providing both high availability and disaster recovery data service exist but such products tend to be expensive and complex. Small and medium sized entities can have difficulties in deploying data storage systems that provide both high availability and disaster recovery services. Thus, it would be desirable to provide systems that provide high availability and disaster recovery data storage service with lower costs and less complexity.

DETAILED DESCRIPTION

The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the invention. It will be apparent to one skilled in the art that specific details in the example embodiments are not required in order to practice the present invention. For example, although some of the example embodiments are disclosed with reference to the Microsoft SharePoint Server environment, other types of server systems may use the teachings in this document. The example embodiments may be combined, other embodiments may be utilized, or structural, logical and electrical changes may be made without departing from the scope of what is claimed. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents.

Computer Systems

The present disclosure concerns digital computer systems.FIG. 1illustrates a diagrammatic representation of a machine in the example form of a computer system100that may be used to implement portions of the present disclosure. Within computer system100ofFIG. 1, there are a set of instructions124that may be executed for causing the machine to perform any one or more of the methodologies discussed within this document.

In a networked deployment, the machine ofFIG. 1may operate in the capacity of a server machine or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a network switch, a network bridge, or any machine capable of executing a set of computer instructions (sequential or otherwise) that specify actions to be taken by that machine. Furthermore, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system100ofFIG. 1includes a processor102(e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both) and a main memory104and a non volatile memory106, which communicate with each other via a bus108. The non volatile memory106may comprise flash memory and may be used either as computer system memory, as a file storage unit, or both. The computer system100may further include a video display adapter110that drives a video display system115such as a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT). The computer system100also includes an alphanumeric input device112(e.g., a keyboard), a cursor control device114(e.g., a mouse or trackball), a disk drive unit116, a signal generation device118(e.g., a speaker) and a network interface device120. Note that not all of these parts illustrated inFIG. 1will be present in all embodiments. For example, a computer server system may not have a video display adapter110or video display system115if that server is controlled through the network interface device120.

The disk drive unit116includes a machine-readable medium122on which is stored one or more sets of computer instructions and data structures (e.g., instructions124also known as ‘software’) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions124may also reside, completely or at least partially, within the main memory104and/or within a cache memory103associated with the processor102. The main memory104and the cache memory103associated with the processor102also constitute machine-readable media.

The instructions124may further be transmitted or received over a computer network126via the network interface device120. Such transmissions may occur utilizing any one of a number of well-known transfer protocols such as the well known File Transport Protocol (FTP).

For the purposes of this specification, the term “module” includes an identifiable portion of code, computational or executable instructions, data, or computational object to achieve a particular function, operation, processing, or procedure. A module need not be implemented in software; a module may be implemented in software, hardware/circuitry, or a combination of software and hardware.

Server Systems

Client-Server computing is a computer paradigm wherein a centralized server system provides services to one or more client computer systems. Computer servers have been created to provide a wide variety of different services to client computer systems such as general file storage, email service, web site hosting, and database service.

FIG. 2Aillustrates a block diagram of an example client-server environment. InFIG. 2A, a front-end server system231provides a service to multiple client systems221,222, and223. In the client-server environment ofFIG. 2A, front-end server system231is supported by a database server233that provides database services to the front-end server231. Furthermore, the database server233is supported by a storage system234. The storage system234may be a storage area network (SAN).

A storage area network allows multiple computer applications (such as database server233) to access remote computer storage devices (such as hard disk arrays, magnetic tape libraries, and optical disc storage devices) in a manner wherein the remote storage devices appear the same as storage devices directly attached to the local computer system. The use of a storage area network (SAN) allows multiple applications and servers to share a unified storage system. The use of unified shared storage simplifies storage administration since only the unified storage system need to be maintained instead of several different storage systems on several different servers. For example, by using a unified storage system234, a single back-up system235can be used to perform data back-ups for all of the applications that use the storage system234.

Data back-up systems are a very basic method of implementing a disaster recovery system. Referring toFIG. 2A, if storage system234stores all of the data at a site and back-up system235creates a duplicate copy of the all the data on storage system234, then back-up system235can be used to fully restore the entire data infrastructure of the site. Thus, if database server233malfunctioned and corrupted all of the data it had stored on storage system234then a back-up copy of that data on back-up system235could be used to restore the data back onto storage system234to resume operation of database server233.

In order to provide a robust data recovery system, the back-up system235or back-up media (tapes, optical discs, etc.) from back-up system235should be moved to a different location than the site that houses front-end server231, database server233, and storage system234. In this manner, a catastrophic disaster (such as a fire) could strike but the data infrastructure ofFIG. 2Acould be rebuilt with new hardware and the data could be restored from the off-site back-up.

In addition to providing disaster recovery services, the back-up system235can handle more mundane back-up data retrieval tasks. For example, if a user accidentally deleted an important file that deleted file could be restored from a recent back-up copy stored on the back-up system235.

High Availability and Improved Disaster Recovery

The data back-up system235ofFIG. 2Aprovides a very basic disaster recovery system. However, when a disaster (such as a fire) occurs it can take a long time to reconstruct the information technology infrastructure ofFIG. 2A. The entire hardware infrastructure must first be rebuilt with new computer hardware and networking equipment. Then the software applications must be loaded onto the new computer hardware. Finally, the backed-up data must be restored onto the reconstructed information technology infrastructure thereby completing the restoration. For any large business or government operation, having such a large amount of down time is unacceptable.

To provide a more robust information technology infrastructure, many entities create a primary computer site and a secondary computer site that can quickly be used if the primary site experiences a catastrophic failure.FIG. 2Billustrates a block diagram of the server system fromFIG. 2Aused as a primary server site239and a secondary server site259that may be used if the primary server site239experiences a failure.

As illustrated inFIG. 2B, the primary server site239and the secondary server site259include the same basic components of a front-end server, a database server, and a storage system. The client systems221,222, and223will generally access the front-end server231at the primary site239. However, if there is a some type of failure at the primary site239, then the client systems221,222, and223can be directed to access the secondary server site259.

For example, if the front-end server231was providing email service, an entry in a Domain Name Service (DNS) entry would designate front-end server251as a back-up server that could be accessed if the primary front-end server231was not responding. Thus, if a disaster were to strike at the primary site239, then front-end server251at the secondary site259would immediately be available to handle service requests from the client systems221,222, and223.

In order to immediately begin handling service requests the secondary site259must be kept up to date with the latest state information from the at the primary site239. Ideally, the secondary site259will have all of the state information from the primary site239but it may be acceptable if the secondary site259is not completely up to date. Various different methods may be used to keep the secondary site259updated with state information. One common technique is to use communication link241between the primary site239and the secondary site259to transmit any data changes made at the primary site239and the secondary site259. In the example ofFIG. 2B, the database server233at the primary site239transmits local data changes to the database server253at the secondary site259such that the secondary database server253remains synchronized with the primary database server233.

Various different methods may be used to maintain synchronization between the primary database server233and the secondary database server253. One technique of updating the secondary database server253at the secondary site259is to use ‘log shipping’. With log shipping, the database server233at the primary site239maintains a log of all the changes made to the primary database on database server233. Then, on a periodic basis, the database server233transmits a batch of changes to the secondary database server253. The secondary database server253then applies the received batch of changes to remain reasonably synchronized with the primary database server233. Note that by collecting the changes and transmitting the changes in batches, the changes may be grouped together and compressed in order to efficiently use the communication link241.

With log shipping, there is delay between when a change occurs in the primary database server233and when that change is eventually packaged up, transmitted, and applied to the secondary database server253. If the primary site239experiences a failure before the latest batch of updates is transmitted, the secondary database server253will not be completely up to date such that a small amount of data may be lost. To reduce this potential loss of data between batches, database mirroring may be employed. With database mirroring, all of the changes that are applied to the primary database server233are immediately transmitted to the secondary site259and applied to the secondary database server253. In this manner, the secondary database server253will be synchronized with the primary database server233. However, this method requires a large bandwidth communication link241between the primary site239and the secondary site259.

Maintaining the secondary fail-over site259is an expensive proposition due to all the hardware and software required to construct and maintain the secondary fail-over site259. Furthermore, with either log shipping or database mirroring, the primary site239and the secondary fail-over site259must be coupled by a high-bandwidth communication link241in order to keep the secondary site259up-to-date with the latest database state information. Maintaining the high-bandwidth communication link241for the secondary fail-over site259that will rarely (or perhaps never) be used is an expensive recurring cost that companies would rather avoid or reduce. And even though the secondary site259acts as a live back-up of the primary site239, some type of back-up system235is still required. For example, the back-up system235and255are still required in order to make periodic back-ups such that accidentally deleted data can be retrieved. Thus, it would be desirable to reduce the cost and complexity of implementing a secondary fail-over site and providing periodic data back-ups.

High Availability and Disaster Recovery at a Reduced Cost with No Link

To simplify the task of creating a fail-over secondary site, the present disclosure proposes using internet-based remote storage services for creating a data store that may be accessed by the secondary site. Internet-based remote storage services store data across the internet which is commonly drawn as a cloud in network diagrams thus these internet-based data storage services are commonly referred to as “cloud storage services”. With the use of cloud-based storage system, the need for a high-bandwidth communication link between the two sites may be reduced or eliminated in some cases.

Cloud-based storage services offer customers reliable off-site data storage at relatively inexpensive prices. By using a cloud-based storage service, an information technology department can outsource the tasks of purchasing and maintaining a system for making data back-up copies. Furthermore, the task of ensuring that back-up copies and transported and stored at an off-site location for protection is completely eliminated since the data is backed-up across the internet to a remote location.

FIG. 3illustrates how a cloud storage service391may be used to provide off-site data storage services to an entity that maintains sever computer server systems. In the diagram ofFIG. 3, a set of client computer systems (321,322, and323) access various servers (331,332, and333) that provide various services such as email service, file server services, database services, etc. In the particular arrangement ofFIG. 3, the servers (331,332, and333) use a storage area network350to store data on a common data storage system342. To back-up the data stored on storage system342, the entity may use the cloud-based data storage service391available on the internet390. Specifically, a data back-up system352backs-up data by transmitting that data to the cloud-based data storage service391. (Note that the use of a storage area network350is just one particular implementation and not necessary in order to use a cloud-based storage service for data back-up operations.)

Cloud-based back-up systems can be implemented in many different ways. One specific cloud-based back-up system that may be employed is disclosed in the U.S. patent application “System And Method For Efficiently Creating Off-Site Data Volume Back-Ups” filed on Apr. 1, 2010 and having Ser. No. 12/798,321 which is hereby incorporated by reference. In that cloud-based back-up system, the data to be stored on the cloud has duplicate data removed, is compressed, and then encrypted before being transmitted to the cloud-based storage service. In this manner, back-up copies of data are created in a very efficient manner that significantly reduces the amount of data that must be transmitted across the internet to the cloud-based storage service. Furthermore, subsequent incremental back-ups may use the data that has already been transmitted to the cloud-based storage service. In this manner, incremental back-ups will only require relatively small amounts of data to be transmitted.

FIG. 4Aillustrates one method of creating operating a secondary fail-over site using cloud-based back-ups. Referring toFIG. 4A, a primary site439operates primarily in the same manner as primary site239illustrated inFIG. 2B. Specifically, a front-end server431at the primary site439serves client computers (421,422, and423) using data from database server433. The database server433uses a storage system434as a bulk storage system to store the actual raw database store436. For example, a Storage Area Network (SAN) system may be used to store the database store436. In one preferred implementation, the storage system434may be the storage system disclosed in the U.S. patent application “System And Method For Efficiently Creating Off-Site Data Volume Back-Ups” filed on Apr. 1, 2010 and having Ser. No. 12/798,321 which is hereby incorporated by reference.

In order to provide the secondary fail-over site459with data in case the secondary site459needs to become operational, the primary site439periodically backs-up the database store436stored on the storage system434using a cloud back-up system437. Specifically, cloud back-up system437periodically creates back-up copies at a cloud storage service491. For example, as illustrated inFIG. 4A, the cloud back-up system437has created three back-up copies (495-1,495-2, and495-3) at the cloud storage service491from the database store436at the primary site439.

If the primary site439were to experience a temporary or catastrophic failure, an administrator could instruct the secondary site459to take-over the role of providing services to the client computers (421,422, and423) using secondary front-end server451. In order to take over these duties, the secondary site459needs access to the most recent back-up copy of the database store436. Thus, before commencing operation, the cloud back-up system457in the secondary site storage system454mounts the most recent back-up volume at the cloud storage service491. For example, the cloud back-up system457may mount back-up volume495-3stored at cloud storage service491. The database server453may then use that back-up volume495-3to support front-end server451.

Note that if the storage system454is serving data directly from the cloud storage service491to the database server453, then there may some latency while requested data is accessed from the cloud storage service491. This latency is an undesirable performance drop. However, this latency can be mitigated in various different manners.

A first method of dealing with this latency is to completely eliminate the latency by copying the entire most recent database back-up (such as back-up volume495-3) into the storage system454before having the secondary site being operating. This allows the data to be served from a local source. However, using this method will mean that no services can be provided to the client computers (421,422, and423) until the back-up volume is fully copied from the cloud storage service491to the storage system454at the secondary site459. Copying a large database may take a significant amount of time and is thus an undesirable option.

A second method of reducing latency is to have the storage system454create a new local database volume456that references the back-up volume495-3stored at cloud storage service491for data that it does not yet have. Since only references to the data in the back-up volume495-3are needed, this new volume can be created very quickly. In this manner, as data requests are received, the storage system454will request data that it does not yet have from by referencing data back-up495-3at cloud storage service491. However, as each referenced data item is accessed, the storage system454can store a local copy of the data in the new database volume456in the local storage system454. In this manner, subsequent requests to the same data can be served using the local copy of the data. Specific details on this technique may be implemented can be found in the section entitled “Restoring a Backed-Up Data Volume” in the U.S. patent application “System And Method For Efficiently Creating Off-Site Data Volume Back-Ups” filed on Apr. 1, 2010 and having Ser. No. 12/798,321 which is incorporated by reference in its entirety.

A third method of mitigating the latency is to have the secondary site459take advantage of data storage systems that are able to identify duplicate data using data fingerprints. Data de-duplication is the process of identifying redundant data and then discarding duplicate data by having two or more data objects that have duplicate data point to a single copy of that duplicate data. One method of identifying duplicate data is to calculate statistically unique data fingerprints for sections of data and then identifying sections of data that have the same data fingerprints. Data duplication provides several advantages such as reducing the amount of storage space required and reducing the time needed to transmit data across communication lines. The system ofFIG. 4Acan take advantage of data de-duplication by using duplicate data that is available locally. Specifically, the storage system459may periodically load recent database back-up copies into the local storage system454. Then, by locating locally available data (data portions from recent back-up copies) with the exact same fingerprints, the storage system454can quickly serve data using the local copy. An example of reduced latency using data-duplication is provided in the following paragraphs.

To prepare for reducing latency by using data duplication with fingerprints, the cloud back-up system457periodically uploads old databases from the cloud storage service491into the local storage system454.FIG. 4Aillustrates an old data back-up476-2that has been uploaded into the storage system454from the cloud storage service491. The uploading of old database may occur less frequently than the cloud back-up system437at the primary site creates back-up volumes in order to reduce bandwidth usage. The uploaded database476-2is comprised of data sections wherein each data section has a statistically unique data fingerprint that is derived from the data section. (The actual creation of the data fingerprints may occur in any location but in one embodiment the data fingerprints are created by the primary storage system434that created the back-up volume.)

When a situation occurs requiring that the secondary site459take over operation, the cloud back-up system457at the secondary site459creates a new data volume456by loading up all the data fingerprints from the most recent back-up volume495-3at the cloud storage service491. Although the loaded data fingerprints are associated with data sections in the most recent back-up volume495-3at the cloud storage service491, any data sections that have the same statistically unique fingerprints may be used. Thus, if there are data sections in the uploaded old database476-2that have the exact same data fingerprints, then the storage system454may respond to requests for that data using the local copy. When the storage system454is able to use a local copy of the fingerprinted data, there will be no latency when responding to such requests. Since much of the data in a large database remains the same, there will tend to be a large amount of duplicate data between an older version of the database476-2that is available locally and the most recent back-up of the database495-3available on the cloud storage service491. Thus, the storage system454will be able to quickly respond to many data requests using local copies of the same data by using duplicate data sections in the locally mounted old database476-2.

The fail-over back-up system ofFIG. 4Aprovides the same type of fail-over back-up system illustrated inFIG. 2Bbut at a lower cost since no high-bandwidth communication line needs to couple the primary site439with the secondary site459. By eliminating that expensive recurring cost, the cost of maintaining a secondary fail-over site is greatly reduced. However, the secondary fail-over back-up system ofFIG. 4Amay lose a significant amount of data when a problem occurs. Specifically, all of the changes made to the database store436at the primary site439since the latest back-up copy stored at the cloud storage service491may be lost. This amount of data loss may be unacceptable for many applications.

High Availability and Disaster Recovery with Slower Communication Link

FIG. 4Billustrates a modified version of the fail-over arrangement ofFIG. 4A. In the fail-over arrangement ofFIG. 4B, the data used to run the primary site has been bifurcated into a bulk data database426and a light data database427. The bulk data database426may be used to store large data items and data items that do not frequently change. The light data database427may be used to store small data items and data items that change frequently. The data in these two databases may come from the database server433or from the front-end server431.

In the fail-over arrangement ofFIG. 4B, the primary database server433uses a communication link441to keep the light data database427synchronized with copy of the light data database477at the secondary site459. Specifically, the primary database server433may communicate any changes made to the light data database427to the secondary database server453such that the secondary database server453may update its local light data database477.

The bulk data database426at the primary site439may be used to store large data objects and data objects that change much less frequently. These data objects may include files such as word processing documents, PDFs, and images. In the arrangement of arrangement ofFIG. 4B, the bulk data database426will be backed-up on a periodic basis to the cloud storage service491.

When disaster causes the primary site439to no longer function, the situation will be as depicted inFIG. 4C. InFIG. 4C, the primary site439has failed and the secondary site459ofFIG. 4Bneeds to begin providing services. Specifically, the secondary front-end server451may begin handling requests from clients421,422, and423by having the secondary database server453use the light data stored in the light data database477which contains the same data that was in primary light data database427. When bulk data is required, the storage system454will access the latest back-up of the bulk data database495-3that is stored at the cloud storage service491.

As set forth with reference to the system ofFIG. 4A, various techniques can be used to reduce the latency of accessing the bulk data database495-3. Specifically, the full bulk data database495-3may be copied to the storage system454, a new bulk database456may be created that references the full bulk data database495-3and caches data locally, or the storage system454may access duplicate data from an older version of a database (not shown) that is available locally in the storage system454.

The fail-over arrangement ofFIGS. 4B and 4C, provides advantages over the fail-over arrangement ofFIG. 4A. With the fail-over arrangement ofFIGS. 4B and 4C, the system will lose less data since all (or most) of the light data will already be replicated over at the secondary site459using database mirroring or log shipping across the communication line241. Only the data stored in the bulk data database426that is not yet in the most recent back-up at the cloud storage service491will be lost if there is a catastrophic disaster at the primary site439. If most of the data stored in the bulk data database426changes only rarely, very little data will be lost Furthermore, since the light data for the secondary database server453will be locally available in light data database477, the performance of the secondary site inFIG. 4Cwill be better than the secondary site inFIG. 4A.

Although the fail-over arrangement ofFIGS. 4B and 4Cis much improved over the fail-over arrangement ofFIG. 4A, there are still some inadequacies. For example, there still may be significant data losses since all the changes made to the bulk data database426since the most recent back-up will be lost. Furthermore, accessing the bulk data back-up from the cloud storage service491may be slow since the data stored at the cloud storage service491may be compressed and encrypted to reduce storage requirements and protect the security of the data. Decompressing and decrypting the data will thus add latency to accessing the bulk data. Thus, the fail-over arrangement depicted inFIGS. 4B and 4Cmay be further improved.

FIG. 4Dillustrates a further improved fail-over arrangement. In the system arrangement ofFIG. 4D, the primary storage system434is a network accessible storage system that may be accessed remotely. Thus, the data in the primary storage system434may be made available for access by the secondary site459across some communication channel249. This may be implemented by coupling storage system434to the internet (such that communication channel249is the internet) and allowing secondary database server453to access the storage system434upon providing proper credentials. Alternatively, the storage system434may be available across a private communication link. For example, a single private communication link241may be used for keeping the light data database477updated during normal operation and then used for remote access to the primary storage system434when the primary server is in maintenance or failure situation.

FIG. 4Dillustrates the server arrangement in a maintenance or failure situation wherein the front-end server431and/or the data server433at the primary site439are no longer available for use. In such a failure or maintenance situation, the secondary front-end server at secondary site459may take over the providing services to the client systems421,422, and423without losing any data at all. Specifically, for light data the database server453at the secondary site459would access its local version of the light data database477and for bulk data the database server453would access the current bulk data database426at the primary site439. In a system that has divided the data well, the most frequently accessed data would reside in the local light data database477such that there would be no latency for most operations. The less frequent accesses to the remote bulk data database426might involve some latency and/or reduced bandwidth due to the database server accessing the bulk data database426from a remote location.

The fail-over systems ofFIGS. 4B to 4Dprovides some advantages over the fail-over system depicted inFIG. 2B. For example, the high-bandwidth communication link241in the system ofFIG. 2Bis not required in the fail-over systems ofFIGS. 4B to 4D. Instead, only a smaller communication link441is required to carry the light data to the secondary database server453in the systems ofFIGS. 4B to 4D. The communication link441that links the two database servers433and453may simply be a standard internet connection that uses encrypted tunneling.

The fail-over systems ofFIGS. 4A to 4Ddo not require an independent back-up solution such as the back-up systems235and255depicted in the arrangement ofFIG. 2B. Instead, the arrangements ofFIGS. 4A to 4Duse a cloud-based back-up system437that may be an integrated part of storage system434. The cloud-based back-up system inherently achieves the goal of having an off-site back-up of data. Furthermore, a single cloud-based storage account at cloud-based storage service491may be shared between both the primary site439and the secondary site459such that only a single back-up system needs to be maintained.

An Example Secondary Site with SharePoint Servers

To fully describe the fail-over system disclosed inFIGS. 4A to 4C, a detailed example of one specific deployment is disclosed with reference toFIGS. 6A to 6C. Referring toFIG. 6A, a Microsoft SharePoint server631is deployed at a primary site639for providing services to several client computers621,622, and623. The SharePoint server631may provide standard web server services along with other services to the client computer systems. Microsoft SharePoint servers are often used as a collaboration system wherein users can share documents with each other.

A Microsoft SharePoint server631is supported by a SQL Server database server633that provides data to the SharePoint server631. In a first mode of operation, the SQL Server database server633can be used to provide all of the data needed by the SharePoint server631. Specifically, the SQL Server database server633serves both meta-data for implementing the SharePoint site and bulk documents shared by the SharePoint users. (The bulk documents may include spreadsheets, word processing documents, and other common document files.)

Although this first mode of operation works fine for small SharePoint deployments, this mode of operation is not ideal for larger SharePoint systems. Specifically, the SharePoint server631and SQL Server database server633may not operate efficiently since the SQL Server database server633will have to handle a very large number of data requests. Furthermore, many of the data requests issued to the SQL Server database server633will be for Binary Large OBjects (BLOBs) that are not handled efficiently by a standard relational database such as the SQL Server database server633. For example, a typical SharePoint server631will be used to share binary large objects (BLOBs) such as word processing documents, images, PDFs, videos, and other large data object files. Although a relational database such as the SQL Server database server633can handle such BLOBs, such BLOBs can be more efficiently handled by a file system. Thus, using a SharePoint server631that is only supported by a SQL Server database server633for all its data requirements is not a solution that can scale up well.

To allow a SharePoint server deployment to scale up to large sizes, Microsoft created an Application Programming Interface (API) into SharePoint that allows SharePoint to store large data objects in a storage system that is separate from the SQL relational database used to support SharePoint. Specifically, Microsoft first introduced an API for External BLOB Storage (EBS) in the 2007 version of SharePoint. More recent versions of SharePoint also support a newer API called Remote BLOB Storage (RBS) for storing BLOBs. The EBS and RBS interfaces allow the SharePoint server to operate in a second mode of operation that allows the data storage requirements to be split among two different data storage systems. Specifically,FIG. 5illustrates a block diagram showing how a SharePoint server510may use both a SQL database and a BLOB storage system (either EBS or RBS) to store data.

Referring toFIG. 5, SharePoint server510uses a SharePoint Object Model521for handling data objects. The data objects are stored using a storage access stack522. In all SharePoint systems, the storage access stack522uses standard relational data access530to access data on a SQL Server database531. The meta-data for implementing the SharePoint server510is stored in the SQL Server database531.

To scale up the storage system for the SharePoint server510, a SharePoint Server510may also support storing binary large data objects (BLOBs) with a Remote or External BLOB Storage (RBS or EBS) system. Specifically, a Remote or External BLOB Storage (RBS or EBS) Application programming interface (API)550allows a Remote or External BLOB Storage (RBS or EBS) “provider”560to provide BLOB storage services. To use a BLOB storage provider, the SharePoint server510creates BLOB identifiers that are stored in the SQL Server database531. The BLOB identifiers are then linked to BLOBs stored using the Remote or External BLOB Storage (RBS or EBS) provider560. Thus, the Remote or External BLOB Storage (RBS or EBS) provider560is an added-on software module that must handle requests to store BLOBs that are associated with a BLOB identifier and retrieve BLOBs using an associated BLOB identifier. The Remote or External BLOB Storage (RBS or EBS) provider560will physically store and retrieve BLOBs using some type of BLOB storage system561. The BLOB storage system561may be a file system, a database designed to handle BLOBs, or any other storage system designed to handle BLOBs.

Referring back toFIG. 6A, the SharePoint Server631at the primary site639stores a first portion data using a SQL Server database server623and stores a second portion data (the BLOB data) with a BLOB service provider632. In the embodiment ofFIG. 6A, both the SQL Server database server623and the BLOB service provider632share the same data storage system634but separate data storage systems may be used in other embodiments. The data storage system634stores the data from the SQL Server database server623in a SQL data volume643and stores the data from the BLOB service provider632in a BLOB storage volume642.

The data storage system634includes a cloud-based back-up system637that may be used to back-up data at a cloud storage service691available on the internet610. As illustrated inFIG. 6A, the cloud storage service691is currently storing a SQL database back-up volume697-1and two BLOB back-up volumes (695-1and695-2). The back-up volumes stored at the cloud storage service691may be used to retrieve data that has accidentally been deleted or may be used when a disaster occurs.

To provide reliable service, a fail-over secondary site659is maintained to provide services to the client computers621,622, and623if the primary site639experiences some type of failure. Like the primary site639, the secondary site659has a SharePoint server651for providing services to the client computers621,622, and623. The SharePoint server651is supported by a SQL Server database server653and a BLOB service provider652. To keep the SharePoint server651at the secondary site659ready for operation, updates applied to the SQL Server database server633at the primary site639are transmitted across communication link641and applied to the SQL Server database server653at the secondary site659. The secondary SQL Server database server653stores the SQL data663in the local data storage system654.

Although the changes to the SQL Server database server are updated at the secondary site659, the changes made by the primary SharePoint Server631to the BLOB service provider632are not immediately transmitted to the secondary site659. Since the BLOB data can account for 90% of the total data volume, this greatly reduces the amount of data that must be transmitted across communication link641. Instead, the BLOB data642at the primary site639is regularly backed-up using the cloud back-up system637. The cloud back-up system637stores the back-up volumes at the cloud storage service691such that the back-up volumes are accessible by the secondary site659.

The back-up volumes created by the cloud back-up system637can be created quickly and efficiently. Incremental back-ups only need to update the portions of a data volume that have changed since the last back-up. And even when full back-ups are performed, techniques that eliminate data duplication can greatly reduce the amount of data that needs to be transmitted to the cloud storage service691when identical data already exists at the cloud storage service691. Details on constructing a cloud back-up system637that identifies duplicated data and eliminates the need for transmitting data duplicates can be found in the U.S. patent application “System And Method For Efficiently Creating Off-Site Data Volume Back-Ups” filed on Apr. 1, 2010 and having Ser. No. 12/798,321 which is hereby incorporated by reference in its entirety. The BLOB data created by a SharePoint server is an ideal candidate for data duplication elimination since SharePoint servers create a completely new BLOB data file in addition to keeping an old existing data file when that old BLOB data file is modified.

The server system arrangement ofFIG. 6Aallows a primary server site639to be supported by a secondary fail-over service site659without significant recurring costs. For example, the communication link641used to keep the SQL Server database server653at the secondary site659updated does not need to be a high-bandwidth connection since by excluding the BLOB updates, the vast majority of the data volume is eliminated. A secured tunnel connection using an ordinary interne connection may suffice instead of needing a private Wide Area Network (WAN) connection. Furthermore, the need for independent back-up systems at both sites is eliminated by using a single shared cloud storage service691that can service both sites.

FIG. 6Billustrates how the arrangement ofFIG. 6Aoperates when a catastrophic disaster (such as a fire) causes the entire primary site639to fail. In such a disaster recovery (DR) situation, the data storage system654at the secondary site mounts the most recent BLOB back-up volume (such as BLOB back-up volume695-3) stored at the cloud storage service691. The data storage system654will use the data from that most recent BLOB back-up volume to create a local BLOB volume662. The SharePoint server651at the secondary site659can the begin providing services to the client computers621,622, and623. Specifically, the secondary SharePoint server651is supported by the SQL Server database server653using mirrored SQL data663and supported by the BLOB service provider652using the BLOB back-up data retrieved from the cloud storage service691. Note that in this situation, the system will lose some data because any changes to the BLOB data volume642that have been made since the latest back-up on the cloud storage service691will be lost. However, with a back-up system that eliminates duplicated data, the BLOB data can be backed-up quickly and efficiently on a regular basis. In one embodiment, the BLOB data store is backed-up several times a day to keep the back-up database relatively up-to-date. But at a minimum, the BLOB data store could easily be backed-up at least every night.

FIG. 6Cillustrates how the arrangement ofFIG. 6Amay operate when only a portion of the primary site639becomes unavailable. For example, if the SharePoint server631, the SQL Server database server633, or the BLOB service provider632were to fail or be taken down to perform maintenance then the primary site639could no longer provide services to the client computers621,622, and623. However, as long as the data storage system634of the primary site639remains operational, then the secondary site659can take over providing services to the client computers621,622, and623without losing any data by directly accessing the data stored in the data storage system634of the primary site639.

When a failure occurs that prevents the primary site639from providing client services yet allows the primary data storage system634to continue functioning, then the BLOB service provider652at the secondary site659may be able to establish a connection644to the data storage system634at the primary site639. This connection644will allow the BLOB service provider652of the secondary site659to directly access the most current BLOB data642which is stored in the data storage system634at the primary site639. In this manner, the SharePoint server651at the secondary site659will be able to provide client services with the support of the SQL Server database server653using the local SQL data663and the support of the BLOB service provider652accessing the current BLOB data volume642on the data storage system634at the primary site639.

In some embodiments, the BLOB service provider652may use various caching systems improve performance. A first caching technique would be to have the data storage system654‘pre-cache’ by having the data storage system654periodically load in a BLOB back-up from the cloud storage service691. Thus, the cloud back-up system657may load a recent BLOB back-up (such as BLOBs back-up695-3) as BLOB store662in data storage system654. The BLOB service provider652will then access a requested BLOB locally from of BLOB store662in data storage system654if it is available in BLOB store662. This will result in improved performance for those BLOB items found within BLOB store662.

When the BLOB service provider652cannot access a requested BLOB locally from the local BLOB store662then the BLOB service provider652will request the BLOB from BLOB store642at primary site639across connection644. When this occurs, the BLOB service provider652may store a copy of that BLOB into the local BLOB store662such that subsequent requests from that particular BLOB can be serviced quickly.

Note that the solution depicted inFIG. 6Crequires the data storage system634to be network accessible. However, that is exactly how Storage Area Networks (SANs) operate. Although accessing the remote BLOB data volume642will likely involve some latency, this may be acceptable during a temporary maintenance time period. It should also be noted that the cloud back-up system637may continue making period back-ups of the BLOB data volume642that can be used if a complete disaster were to take out the primary site639.

Upon the completion of maintenance (or the repair of a failed element), the primary site639should be reactivated in order to obtain the best performance by accessing the BLOB data locally. Before switching back to the primary site639, the data in the SQL data volume663at the secondary site659must be copied to the data storage system634at the primary site639. This may be performed by having the two SQL databases (633and653) re-establish communication and synchronize their SQL data volumes using the SQL data volume663as the data source. Alternatively, service could be temporarily suspended, the SQL data volume663at the secondary site could be backed-up at the cloud storage service691, and then that data could be used to restore a SQL data volume643at the primary site639.

Additional Server Sites for Remote Offices

As an organization grows, that organization may wish to open up geographically remote work sites such as remote satellite offices. To support the users at a remote satellite site, an information technology department may wish provide the users at the remote satellite site with access to the same data available at the organization's headquarter site. However, when a user at a geographically remote satellite site attempts to access a data repository located at the organization's headquarters site there may be significant amount of latency and slow data retrieval when accessing that main data repository. Thus, it would be desirable to find methods of reducing performance problems experienced at remote sites.

FIG. 7Aillustrates a first arrangement that may be used to allow users at a both a headquarters site739and a satellite site759to access data at a headquarters site739that has a main data repository. In the arrangement ofFIG. 7A, the users are accessing data associated with a Microsoft SharePoint server731, however other types of data and server systems would operate in a similar manner. A set of user workstations721,722, and723at the headquarters site739access a local SharePoint server731that stores data using a SQL Server database server733and a BLOB service provider732. The raw data for both the SQL Server database server733and the BLOB service provider732is stored on a data storage system734as SQL data743and BLOB data742, respectively.

To access the same SharePoint data from the satellite site759, the users at workstations727and728at satellite site759may access a local SharePoint server751. The local SharePoint server751at the satellite site759then accesses the SQL Server database server733and BLOB service provider732at the headquarters site739across a communication channel741to obtain the needed SharePoint data. In the embodiment ofFIG. 7Athe communication channel741is implemented using the Internet710but any type of suitable communication line (such as a private communication line) may be used instead.

With the arrangement ofFIG. 7A, the users at workstations727and728at the satellite site759have a good direct connection to local SharePoint Server751. However, since all of the underlying data for SharePoint Server751is located at the headquarters site739, the performance of the arrangement ofFIG. 7Awill be less than desirable for the users at the satellite site759. Specifically, the performance will only be as good as the communication channel741. And even with a high-quality communication channel, a geographically remote site will have to deal with propagation delay along the communication channel741. With a satellite office located on the other side planet, the remote office may experience delays of 600 milliseconds or more. In addition to the propagation delay, there may be a significant cost to transmitting large amounts of data to the other side of the planet. To significantly improve the performance of the system for the users located at the satellite site759, the SharePoint server751at the satellite site759needs to be able to access to local SharePoint data.

FIG. 7Billustrates an improved arrangement for implementing a remote satellite site759that has access to a remote SharePoint system. In the embodiment ofFIG. 7B, the SharePoint server751at satellite site759continues to access a SQL Server database server733at the headquarters site739for SQL data requests and responses. However, the satellite SharePoint server751accesses a local BLOB service provider752at the satellite site759for all requests of BLOB data. The local BLOB service provider752obtains BLOB data from a local satellite BLOB data store762whenever possible. When requested BLOB data is not available locally, then the local BLOB service provider752will access requested BLOB data from the main BLOB data store742at the headquarters site739. When the local BLOB service provider752is accessing local BLOB data stored in local BLOB data store762, then the latency will be low.

In the environment ofFIG. 7B, the satellite BLOB data store762will generally not be an identical copy of the main BLOB data store742. Instead, the satellite BLOB data store762may only contain BLOB data items that were previously accessed by a user at the satellite site759or were created by a user at the satellite site759. When a user at the satellite site759attempts to access a BLOB data item that is not available in the satellite BLOB data store762then the satellite BLOB service provider752will access the main BLOB data store742at the headquarters site739using communication path747to retrieve the missing BLOB data item. (Note that Communication line747may be implemented using the interne710as illustrated inFIG. 7Bor with a different communication line.) The BLOB data item retrieved from the main BLOB data store742at the headquarters site739will then be provided to the user that requested the BLOB data item. The satellite BLOB service provider752will also store the retrieved BLOB data item into the local satellite BLOB data store762. This creation of a local copy when first accessing a BLOB data item that is not available locally is known as a ‘copy on first read’ strategy. By storing a copy of the retrieved BLOB data item into the satellite BLOB data store762after it is first retrieved, that particular BLOB data item can then be accessed locally for all subsequent requests of that specific BLOB data item.

When a user at the at the satellite site759creates a new BLOB data item, then the satellite BLOB service provider752will only create a local version of that BLOB data item in the satellite BLOB data store762. However, information about that new BLOB data item will be transmitted to the headquarters site739in the form of a BLOB identifier presented to the SQL Server Database Server733. Thus, the SharePoint Server731will know about the new BLOB data item but will not have a local copy.

The BLOB service provider732in the headquarters site739may be implemented in the same manner with the same ‘copy on first read’ strategy. Thus, when a user at the headquarters site739attempts to access a BLOB data item, the BLOB service provider732will first attempt to access that BLOB data item from the main BLOB data store742at the headquarters site739. When that data item is not available in the main BLOB data store742at the headquarters site739, then the BLOB service provider732will access the satellite BLOB data store762at the satellite site759using communication line748to retrieve the requested BLOB data item. The BLOB service provider732will provide the BLOB data item to the user that made the request and also store that BLOB data item in the main BLOB data store742for all subsequent requests of that same BLOB data item by users at the headquarters site739. Thus, a copy on first read occurs when first accessing a BLOB data item that is not available in the main

The arrangement ofFIG. 7Bcan be implemented easily for a SharePoint server system because SharePoint never changes existing BLOB data items. Instead, anytime that a change is made to a BLOB data item handled by a BLOB service provider, the SharePoint server will create a new file for the changed BLOB data item. Thus, with a SharePoint server system, there are no difficult cache coherency issues that can occur with the two BLOB data stores742and762. Thus, there is no need to implement semaphores or any file-locking systems to prevent two users from accessing the same file concurrently.

The server arrangement ofFIG. 7Bmay provide significant tangible resource savings. Specifically, the server arrangement ofFIG. 7Bwill minimize the use of network bandwidth and storage capacity by sharing only the BLOB data items that both the headquarters office and the satellite office use. If there are BLOB data items at the headquarters site739that only pertain to the headquarters site739(such as documents related to the headquarters building maps, the local softball team, parking arrangement at the headquarters, etc.) and are never accessed by users at the satellite site759then those BLOB data items will never be transmitted to nor stored at the satellite site759. Similarly, if there are BLOB data items at the satellite site759that only pertain to the satellite site759and are never accessed by users at the headquarters site739then those BLOB data items will never be transmitted to nor stored at the headquarters site739. Both sites may therefore need back-up systems in order to protect all of the organization's data. However, the two sites may share a single account at a cloud storage service791to perform these back-ups.

The amount of data that transmitted between the headquarters site739and the satellite site759is greatly in the system ofFIG. 7Bwhen compared to the system ofFIG. 7A. Although SQL requests and responses still travel between the SharePoint server751at satellite site759and the SQL Server database server733at the headquarters site739, this represents a small volume of data traffic. In a typical SharePoint deployment, 85% to 95% of the data served by a SharePoint server tends to be the BLOB data. Thus, in the embodiment ofFIG. 7B, 85% to 95% provided to users727and728may be served locally from the satellite BLOB data store762in local data storage system754. Thus, the arrangement ofFIG. 7Breduces costs by greatly reducing the amount of data traffic between the headquarters site739and the satellite site759.

The Abstract is provided to comply with 37 C.F.R. §1.72(b), which requires that it allow the reader to quickly ascertain the nature of the technical disclosure. The abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.