Vault to object store

Systems and methods of enabling a service level agreement to specify interactions between an application and a remotely located object store that manages data as objects. A computing device receives data associated with a request to write application data to an object store according to a schedule, wherein the data is file system data. The computing device creates a snapshot associated with the requested application at a snapshot pool, and transmits instructions to a cloud formatting engine to create a virtual disk at a storage pool associated with an object store. The computing device copies the snapshot from the snapshot pool to the virtual disk, the snapshot comprising file system data and transmits instructions to the cloud formatting engine to convert the data associated with the first snapshot into an object, and move the object from the virtual disk to the object store.

TECHNICAL FIELD

This invention relates generally to data management, data protection, disaster recovery and business continuity. More specifically, this invention relates to a system and method for reading and writing data to object storage.

BACKGROUND

Copy data systems (e.g., Actifio copy data systems such as CDS and Sky) typically use block input/output (I/O) when replicating copy data to a remote target CDS using asynchronous deduplication and dedup replication. Block I/O usually includes writing and reading data that is organized as logical blocks (e.g., 512 byte blocks). Block I/O maintains an address for the logical blocks, but does not keep hierarchical information about data objects associated with the logical blocks. In contrast, object data stores organize data as objects and tracks hierarchical relationships between data objects. Object stores offered by both public and private cloud providers offer cost effective means for long term data retention (e.g., 7 years or more). The reliability of these object stores make them effective replacements to the existing tape technology. As existing copy data systems use block I/O to replicate data to a remote target, existing copy data systems do not have the capability to read or write from an object data store at a remote target.

SUMMARY OF THE INVENTION

In accordance with the disclosed subject matter, systems, methods, and non-transitory computer-readable media are provided for enabling a service level agreement to specify interactions between an application and a remotely located object store that manages data as objects.

In some embodiments, the disclosed subject matter includes a method for receiving first data associated with a first request to write application data to an object store according to a first schedule, wherein the first data is file system data. In some embodiments, a computing device creates a first snapshot associated with the first requested application at a snapshot pool. In some embodiments, the computing device transmits first instructions to a cloud formatting engine to create a first virtual disk at a storage pool associated with an object store, the first disk being structured to accept file system data. In some embodiments, the computing device copies the first snapshot from the snapshot pool to the first virtual disk, the first snapshot comprising file system data. In some embodiments, the computing device transmits instructions to the cloud formatting engine to convert the data associated with the first snapshot into an object, and move the object from the first virtual disk to the object store, thereby enabling a service level agreement to specify interactions between an application and a remotely located object store that manages data as objects.

In some embodiments, the computing device receives second data associated with a second request from a requesting application to read application data from the object store at a first time. In some embodiments, the computing device transmits second instructions to the cloud formatting engine to mount a second snapshot, the snapshot associated with the second data, and present the second application image as a second virtual disk on the storage pool associated with the object store. In some embodiments, the computing device presents the second virtual disk to the requesting application at a second time.

In some embodiments, the computing device provides a scratch disk to cache writes associated with the second snapshot, the cache writes including identification information associated with the second snapshot. In some embodiments, the difference between the first time and the second time is approximately 2 minutes. In some embodiments, the object store is associated with a long-term storage of the application data. In some embodiments, the computing device creates a directory structure associated with the object store, the directory structure comprising a logical representation of the object store. In some embodiments, the first instructions include data associated with the directory structure.

These and other capabilities of the disclosed subject matter will be more fully understood after a review of the following figures, detailed description, and claims. It is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

DETAILED DESCRIPTION

Systems and methods described herein enable copy data systems to read and write from an object data store. Service level agreements (SLAs) can be configured to include policies that schedule replication of data to object storage (e.g., from snapshot storage to object storage). In some embodiments, the systems and methods described herein treat the object storage as another storage tier and the copy data system manages the metadata for images in the object store. Some embodiments also include a desktop that is used to manage both a copy data appliance and to retrieve or mount images from the object store. The systems and methods described herein also allow multiple vault pools each backed by an associated object store. For example, end-user can choose to move one set of applications to a first storage, (e.g., Google Nearline), and another set of applications to a second storage, (e.g., Amazon S3), all controlled by an SLA that governs the application.

FIG. 1is a system diagram showing the movement of snapshot data to a remote filesystem during copy data replication.FIG. 1shows a primary site102and data replication site104. Primary site102includes applications110, copy data management system112, snapshot pool114, and dedup pool116. Disaster recovery site104includes copy data management system120, dedup pool122, snapshot pool124and replicated data126.

Primary site102is the location of end-user's production data and applications. There is a copy data management system112installed on the primary site102. The copy data management system112manages 2 pools of storage:1. snapshot pool114: Snapshot pool114includes images of applications110. The images can be associated with snapshots of the applications data taken at different points in time. A schedule for capturing snapshots of the application data can be specified by a service level agreement (SLA).2. Dedup pool116: Dedup pool116includes images from the snapshot pool114and are stored in a de-duplicated form.

Copy data management system112from the primary site102replicates to another copy data management system120which is installed in the disaster recovery site104. Copy data management system120also contains a snapshot pool124and a de-duplication pool122. As described above, data is de-duplicated and compressed on the primary site102prior to replication. Replicated data lands in the de-duplication pool122on the disaster recovery site104. This data is then re-hydrated and moved to the snapshot pool124and applications126on the Disaster Recovery site104can then access this data.

The workflow for migrating data from primary site102to disaster recovery site104begins with data being ingested either into the snapshot pool114or the de-duplication pool116on the primary site102. If data is ingested in the snapshot pool114, it is moved to the de-duplication pool where it is compressed and de-duplicated. Data is then replicated from the primary site102to the de-duplication pool122on the disaster recovery site104. From the de-duplication pool122on the disaster recovery site104, data is rehydrated into the snapshot pool124. Once data is in the snapshot pool124, applications126can access this data. Additional details describing the movement of snapshot data to a remote filesystem during copy data replication can be found in U.S. application Ser. No. 12/947,385, titled “System and Method for Managing Data with Service Level Agreements That May Specify Non-Uniform Copying of Data,” filed Nov. 16, 2010, the contents of which are incorporated herein in its entirety.

FIG. 2is a system diagram showing the movement of snapshot data to a remote object storage during copy data replication, according to some embodiments of the present disclosure.FIG. 2shows a primary site202and cloud object storage206. Primary site202includes applications110, copy data management system216, snapshot pool114, dedup pool116, vault pool214, scheduler208, unified data processing (UDP) engine210, and cloud formatting engine212.

As described above, application110is being protected at copy data management system216. The SLA for this application is configured by copy data management system216(also referred to herein as copy data system and copy data appliance) to vault to object store206(e.g., Google Nearline Object store). Copy data management system216moves application images from snapshot pool114to object store206per a defined application SLA. For example, the application SLA can call for periodic vaulting of these application images to object store206.

Unified Data Processing (UDP) Engine210, which receives instructions from a scheduler within copy data management system216, coordinates the movement of application images snapshot pool114to object store206. In some embodiments, the scheduler208executes jobs per policy in the copy data management system216. Copy data management system216provides policy based data management for all applications. End users can create policies that govern the life cycle of a given application. The scheduler208provides life to this policy by actively executing tasks (also referred to herein as jobs) to ensure that applications adhere to the policies they are assigned. Vaulting data to an object store206can also be specified as a policy. For example, when this policy is applied to an application the scheduler208can ensure that the corresponding application data is vaulted to the object store206as specified in the policy. In addition to starting jobs to vault data to object store, the scheduler208can also look at the life cycle for vaulted data and expire jobs when data is past the retention period specified in a vault policy.

The UDP engine210is the data processing entity in the copy data management system216. The UDP engine210receives input from the scheduler208for performing a variety of operations based on the source and target of the application being manipulated. For example, UDP engine210can receive instructions to vault data into an object store from scheduler208. UDP engine210orchestrates this data movement by invoking (e.g., sending instructions to) the cloud formatting engine212to perform the actual data movement. The UDP engine210also generates the metadata for this data movement that it persists after completion. Upon completion, the UDP engine210then informs the scheduler which then re-schedules this job for the next run. Specifically, the UDP engine210sends an instruction to the cloud formatting engine212to mount the object store as a local file-system. UDP engine210then initiates the data copy into the object store by copying the source data (located in the snapshot pool114) to the mount point. The cloud formatting engine212in turn moves this data to the object store, optimizing the writes for the best performance. In some embodiments, writes are performed at a 64K boundary using a method that by-passes file-system caching (e.g., O_DIRECT). Using O_DIRECT, for example, also avoids a typical read-modify-write scenario where a partial block write needs to fetch data from the disk modify it and then rewrite it back to disk. The effect of these partial-block writes can be many orders of magnitude worse when writing to cloud storage as the initial fetch of the block of data happens from the object store, which can be a high latency operation. Using O_DIRECT, for example, can have dramatic performance improvements in a vault job performance. In some embodiments, increased and sustained network utilization can be required for optimal performance.

The Unified Data Processing (UDP) Engine210receives data associated with an instruction from scheduler208in the copy data system216to move data between various tiers of storage (e.g., snap pool114, dedup pool116, vault pool214). Copy data system216has 3 tiers of storage—1. Snapshot Storage Pool114—In some embodiments, this is the highest performing storage tier under management of the copy data management system216. Data is typically moved from production storage, which is associated with applications110, to snapshot pool114. In some embodiments, snapshot pool114is the first storage tier where copy data is created.2. De-duplication Pool116—In some embodiments, this tier of storage is used for medium term (e.g., read every 3-6 months) data retention. Data is typically moved from snapshot pool114to the de-duplication pool116. Copy data system216can provide global de-duplication across all applications data under management.3. Vault Pool214—In some embodiments, this tier of storage is for long-term (e.g., read 1-7 every years) data retention. Vault pool214a logical entity in copy data system216and can be backed by a public or private object store.

As described above, UDP engine210supports vault jobs. In some embodiments, vault jobs move data from snapshot pool114to vault pool214, thus moving data to object stores for long term retention. UDP engine210can also manage clone and mount jobs that provide end users access to data in object store. Clone jobs can move entire data sets from object store206to snapshot pool114while mount jobs provide instant (or near instant) access to data on object stores206. Instant access as referred to herein refers to near instant access and is associated with certain times as described in more detail below. As part of life-cycle management, UDP engine210can also expire jobs from object store206when the data has reached its retention.

Object store206is logically presented to copy data management system216as vault pool214. The vault pool214is a logical representation of the cloud based object store206. Unlike the snap pool114or the dedup pool116copy data management system216does not actively manage this storage. Vault pool214is a logical representation of the remote cloud object store that the cloud formatting engine212presents as a local data store. In some embodiments, an end user can have multiple vault pools each represented by a different cloud based object store.

Cloud formatting engine212presents a disk like block storage interface for object store206. In some embodiments, cloud formatting engine212is a file system in user space (FUSE) based program and presents a logical disk interface to an object store back-end206. Filesystem in Userspace (FUSE) is a software interface for Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a bridge to the actual kernel interfaces. FUSE is particularly useful for writing virtual file systems. Unlike traditional file systems that essentially save data to and retrieve data from disk, virtual filesystems do not actually store data themselves. They act as a view or translation of an existing file system or storage device.

In some embodiments, any resource available to a FUSE implementation can be exported as a file system. Cloud formatting engine212transfers data to object stores, keeping a catalog of objects in the object store and also provides the capability to mount data for instance access from the object store (e.g., S3Backer that interfaces to Amazon Web Services' (AWS) object store S3). In some embodiments, cloud formatting engine212also includes a block naming scheme for an object store (e.g., AWS). To avoid metadata processing hotspots associated with an object store, in some embodiments, consecutive block IDs do not translate to object names with common prefixes. In some embodiments, the cloud formatting engine212includes an asynchronous option of filling out a non-zero block bitmap (used to optimize out reads/writes of zero-filled blocks). This allows for a local device to store incremental changes to a bucket on a local block device while leaving a cloud data set immutable. With this enhancement, cloud data can be presented as a read-writeable mount to a host. All writes coming from a host will be sent to the local device thus leaving the cloud data unchanged. Data in the object store, which is often used for long term retention, can be immutable thereby leaving the archive copy untouched for compliance purposes.

In some embodiments, cloud formatting engine212includes error handling to recognize error types that do not need retries and a storing bucket configuration (e.g., block size, dataset size, compression/encryption settings (on/off), etc.) in the cloud to minimize (critical) mistakes leading to the loss of data. In some embodiments, cloud formatting engine212includes an authentication mechanism that performs authentication using native security APIs from other vendors (e.g., Google Nearline's native security APIs). Including this authentication mechanism allows the copy data management system216to work with object stores from different vendors (e.g., Google Nearline, which is Google's public object store). In some embodiments, cloud formatting engine212can talk to multiple object store providers like Google, Microsoft Azure etc. In some embodiments, cloud formatting engine212includes a separate authentication layer to authenticate with native APIs from a plurality of different vendors. The authentication layer includes authentication modules that are specialized for various storage backends. In some embodiments, the cloud formatting engine212includes a security module with new interfaces that can take a generic set of parameters as deemed necessary by an object store vendor cloud formatting engine is writing to. The parameters can be customized per a cloud provider's requirements. For example, the parameters can include bucket-name, access-id and access-key for an Amazon S3 Backer and a bucket-name P12 certificate for Google.

For moving data to object storage206, UDP engine210creates vault application images on the disk presented by cloud formatting engine212. Cloud formatting engine212in turn converts this application image to objects and dispatches them to the object store206as configured by the SLA. UDP engine210interacts with cloud formatting engine212and moves application data110to the vault pool214. As described above, vault pool214is a logical end point for the cloud storage206presented by cloud formatting engine212. Cloud formatting engine212in turn moves this data to the object store206as specified in the policy. The end user configures a vault pool214on a user interface, which is shown and described in more detail below. The vault pool214is backed by an object store of the user's choice. As part of the configuration the end user also configures the storage entity and the access controls for the object store. Copy data management system112validates the access controls as part of initializing the vault pool214. Once initialized the vault pool is ready for use. Once created, vault pool214can be used as a resource in any SLA template. The applications that are governed by this template can vault data to the vault pool214that is specified. The UDP engine210creates a directory structure on the local appliance that serves as a logical representation of the object store. In some embodiments, the directory structure is created under the/(“root”) partition and an application's ID is used as a sub-directory where the vault images are created. Each vault image is given a unique name that is unique in the global namespace of all images in that object store. Appliance ID, application ID, backup-image ID and a time-stamp make up the unique application ID for a given image. This directory structure is then passed to cloud formatting engine212for it to use as a logical end point of the object store. This logical end-point is the mount point for the image that is stored in the object store206. The image actually is not located in the directory but is mounted to a location specified by the directory. This establishes the link where any file transferred to that end point is automatically sent to the object store that is backed by the end point. Vaulting jobs run by the UDP engine210involves copying the data to the logical end point at which point cloud formatting engine212automatically moves this data to the object store backing this logical end point.

In some embodiments, each image that is vaulted can be assigned a specific prefix or identifier to easily find it in the object store. The prefix helps the object store index these images efficiently for faster access. The index assigned to each vault image is also stored in metadata. In some embodiments, data stored in the object store is split into one or more small object files such that every volume stored in the object store is given a unique prefix. Copy data management system216protects application data along with its associated metadata when moving data from the snapshot pool to vault pool214. The metadata object describes the application data and can be used to restore this application data. For file-system data, the metadata describes the file-system type and options to mount the file-system. For database applications such as SQL and Oracle, metadata can contain the database name and configuration data to recover the database. In some embodiments, metadata is stored as an object in the vault object store. A special object name (“metadata”) can be used as prefix for the metadata objects. Metadata can also include information about data volumes.

FIG. 3is a system diagram showing a mount of application images from an object store, according to some embodiments of the present disclosure.FIG. 3shows similar elements asFIG. 2, which operate in a similar fashion as described above.

Once an application110has been vaulted to an object store206, copy data management system216, enables a mount of that image with very limited data movement. An advantage to mounting with limited data movement is nearly instant access to data stored at the object store206. A mount is initiated when the end-user wants a second or an older copy of application data110that has been moved to object store206. As described in more detail below, in some embodiments, UDP engine210receives an instruction associated with a user request through a user interface to present a volume of data as a disk to a specified host. The UDP engine210in copy data appliance216looks up in its metadata and determines that the image being asked for has been vaulted to the object store1009. The UDP engine210also fetches from the metadata the prefix associated with this image. The UDP engine210then invokes cloud formatting engine212with the image name and prefix and sends instructions to the cloud formatting engine212with a request to present a logical mount of this image to a logical end point in the vault pool214on the appliance that represents remote object store206. Copy data management system216then makes a logical mount of that application image as a disk on itself and then presents that disk via a local-area or wide-area network (e.g., iSCSI) to the application requesting the mount. UDP engine210can also present a scratch device to this mount to cache all the writes that come from the host. In some embodiments, the writes are cached and saved until the host holds on to the mount. These writes and the scratch disk itself are discarded once the host releases the mount using the un-mount operation.

As discussed above, near instant access as described herein can be associated with certain timings. For example, the time associated with cloud formatting engine212completing the request to mount a volume from the object store can be approximately one minute or less (e.g., 5-60 seconds). The time associated with presenting the disk can be approximately a few seconds (e.g., 1-10 seconds). The time associated with processing metadata can be approximately a few seconds (e.g., 30-60 seconds). As a result, the total time associated with a user requesting a copy of application data at an object store to the time the requested data is mounted at the specified host can be approximately 2 minutes. As described above, since there is very limited data movement associated with the mount, the time for mounting data of any size, be it a few megabyte file or a few terabyte file is the same.

FIG. 4is a flowchart illustrating techniques for backing up an image to object storage, according to some embodiments of the present disclosure.

UDP engine210receives instructions from scheduler208to move application images into the snapshot pool114per a configured SLA402. As described above, an SLA can specify a schedule for taking snapshots of application data (e.g., once every hour, once a day, once a week). Next, UDP engine210receives a request to vault application data404. The request includes a specification of a vault pool. After receiving the request and a specification of a vault pool, UDP engine210sends an instruction to cloud formatting engine to create a logical file-system at the specified vault pool representing the object store214406. The application image is then copied to the file-system at the vault pool408. Cloud formatting engine212, which manages the vault pool, in turn moves this data into the backing object store206406. UDP engine catalogues the stored application images in a job catalog database.

FIG. 5is a flowchart illustrating techniques for mounting an image from object storage, according to some embodiments of the present disclosure.

When an end-user requests a mount of an application image at object store502, UDP engine210invokes cloud formatting engine212to mount that image logically on the vault pool214504. Cloud backer212looks up the application image and presents it as a disk on the vault pool214. UDP engine210then presents this disk to an application (specified by the end-user) via the iSCSI protocol506. UDP engine210also provides a scratch disk to cache all the writes coming to this image. Most operating systems require writing header and drive information to any disk they are mounting. Microsoft Windows, for instance, assigns drive letters to mounts, and Linux assigns IDs to drives such that the drives are unique in the system. Disks that are mounted read-only require supporting small amount of metadata writes. Vault jobs, in contrast, write to object stores and the primary intent for long term data retention is to ensure that the written data is immutable. In some embodiments, when mounting data from object stores, copy data appliance also provides a thin provisioned disk (referred to herein as a scratch disk) to support small metadata writes. The scratch disk buffers all the writes that come to the mounted disk (from the object store). This provides an application the ability to write metadata and for copy data appliance the ability to keep the data in the object store intact. Because the data in the vault can be immutable, in some embodiments, the writes to the scratch disk are discarded upon unmount.

FIG. 6is a screenshot showing assigning a service level agreement to an application, according to some embodiments of the present disclosure.FIG. 6shows SLA configuration on a desktop602that is the user interface to configure and manage a copy data management system as described herein. Desktop602includes data management tabs640to manage various aspects of application data life cycle. Application section650describes hosts and associated applications under management. Details section604include details specific to an application residing on a host and the associated policy. Settings section606shows the details of the policy when applied to an application. The details section604provides information on the host that is hosting the application that is under management. It provides the host-name, IP address and the application size as discovered by copy data management system. It also provides overrides to disable this application from being scheduled652and from scheduler running any expiration jobs that delete copies older than what is in the retention part of the policy654. These overrides are in place so a policy can be altered temporarily either due to a change in requirements or for troubleshooting problems.

Data management tabs640include a protect tab, a policies tab, a restore tab, a replication tab, a workflow tab, and an organization tab. Protect tab, as shown inFIG. 6manages data protection aspects which includes how often data is protected and how long it is kept in the various storage tiers (snapshot pool624, dedup pool626and vault pool618). The protection tab also describes how often data is moved from snapshot to dedup and snapshot to vault pools.

Policy tab allows changing the above mentioned time intervals for protection and data lifecycle management. Restore tab is used to present data back to a host via a mount or by actually moving data to the host. For data vaulted to object stores, copy data appliance presents two options, clone to bring data back from the object store and mount which provides instant (or near instant) access to data in the object store. The replication tab indicates details on which another appliance is connected to the appliance illustrated inFIG. 6and how data replication is progressing between appliances. As shown in theFIG. 6, 630, 632 and 634represent application (630), snapshot (632) and de-duplication (634) pools on one remote copy data appliance. The storage pools that are on the remote appliance630include the production storage632and a deduplication pool634. Orgs tab presents users and roles to manage various aspects of the appliance. An admin role will have access to everything and the admin user can create other roles that restrict access to some portions of the appliance.

The setting tab606includes a template feature608, a local profile feature610and a protect/unprotect feature612. The SLA template feature608allows a user to specify an SLA template that can vault data from the snapshot pool624. The Vault Policy628controls how often images are sent to the vault pool618. The vault policy628includes specification of a schedule that dictates how often the scheduler begins vault jobs. The vault policy628also indicates the resource (also referred to herein as object store) that is used by the vaulting jobs. The template608specifies which Service Level Agreement to use for vaulting data to object store628. Vault Policy628also manages the lifecycle of the images in the object store (not shown).

The template610inFIG. 6shows the SLA template that is governing the application650. The SLA template controls when data is moved to snapshot pool624from application storage622, de-duplication pool626and to Vault Pool618. The profile612indicates which resources are to be used by this policy, primarily which snapshot pool624and which Vault pool618.

Once an SLA template with Vaulting as a component is created it can be applied to applications discovered and managed by the data management appliance. As shown inFIG. 7an application is being protected by a template that has vaulting as a component.

FIG. 7is a screenshot of a desktop702showing the restore tab, according to some embodiments of the present disclosure. The restore tab720allows a user to restore or mount data that is being managed by a copy data management appliance. The other tabs in702are described above with respect toFIG. 6. The restore tab720shows applications in various tiers of storage (e.g., snapshot, dedup and also vault732). End user can click on any image in the vault tab and ask for that image to be restored or mounted. If the image is to be restored, UDP engine invokes the cloud formatting engine requesting the image data to be mounted and then copies the image from the logical end point of the vault pool to the snapshot pool. If the image is to be mounted, UDP engine invokes cloud formatting engine to request that the image data be mounted and then presents this mount point as an iSCSI target to the client machine.

Along with the various tiers of storage732, user can also select a time-range to view list of available images708in that time-window. The list708is adjusted per the tier of storage732and the time range710.