Live object level inter process communication in federated backup environment

In one embodiment, a sender process on a node of a node cluster communicates a live object to a receiver process. The sender process determines a shared binary file and a shared file location. The sender process serializes the live object to be communicated to a receiver process, into a binary data stream and writes the binary data stream into the predetermined shared binary file. The receiver process receives a shared binary filename and the shared location associated with the shared binary file. The receiver process de-serializes the binary data stream and reconstructs the live object. The communication is independent of the type of proxy, i.e., virtual or physical, and operating systems of the proxies, such as Windows, Mac OS, or Linux. The live objects may be VM configurations and VHD information metadata.

FIELD OF THE INVENTION

Embodiments of the present invention relate generally to data storage systems. More particularly, embodiments of the invention relate to inter process communication of live objects in a federated backup environment to enable parallel data rollover by dedicated backup proxies (virtual machines) running in the federated backup environment.

BACKGROUND

A federated backup environment is an environment in which back up of data is distributed among multiple nodes in a cluster and/or virtual machines running on a hypervisor cluster. Such a federated backup environment typically has data stored on a cluster shared volume (CSV) accessible by all nodes of the cluster for read and writes. Furthermore, each of the virtual machines (or virtual proxies) or physical nodes in the cluster is not restricted to any particular operating system, such as Windows, Linux, Unix, or a mix of them.

A need had arisen to transfer live objects (objects created in a process which has not been destroyed) from one process to another among a node cluster to facilitate parallel backup operations. The transfer of live objects from one process to another process on a cluster should not be restricted to the operating environment or physical location of a node in a federated backup environment to help customers to use virtual machines from any operating systems or vendors for data rollover operation.

DETAILED DESCRIPTION

Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in conjunction with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment. A Cluster Shared Volume (CSV) is a shared disk containing an NT file system (NTFS) or Resilient File System (ReFS) (ReFS: Windows Server 2012 R2 or newer) volume that is made accessible for read and write operations by all nodes within a Windows Server Failover Cluster. A CSV provides simultaneous read-write access to a shared volume by all nodes of the cluster. A “federated backup environment” is an environment in which back up of data is distributed among multiple nodes in a cluster and/or virtual machines running on a hypervisor cluster. A “live” object refers to data object which is created in a process and has not been destroyed. A proxy refers to a computer or a software system running on a computer that acts as an intermediary between an endpoint device, such as a computer, and another server from which a user or client is requesting a service. A virtual proxy refers to a virtual machine.

According to some embodiment, a snapshot module (e.g., a sender process) of a physical node in a node cluster transports live objects to one or more rollover modules (e.g., receiver process) of a plurality of virtual machines in the node cluster (or hypervisor cluster). The sender process determines a shared binary file and a shared file location. The sender process serializes a live object to be communicated to a receiver process, into a binary data stream and writes the binary data stream into the predetermined shared binary file. The receiver process receives a shared binary filename and the shared location associated with the shared binary file. The receiver process de-serializes the binary data stream and reconstructs the live object. The first node is different from the second node but both the first and the second nodes are on the same node cluster. The communication is independent of the type of proxy, i.e., virtual or physical, and the operating systems running on the proxies, such as Windows, Mac OS, or Linux. The live object may be information that enables a parallel data rollover (or backup rollover) by backup proxies, such as a data object of VM configurations and VHD information metadata.

According to some embodiment, a snapshot module (e.g., a sender process) of a physical node in a node cluster transports live objects to one or more rollover modules (e.g., receiver process) of a plurality of virtual machines in the node cluster (or hypervisor cluster). The snapshot module serializes a list of one or more live objects into a stream of binary data in the order according to occurrence of the one or more live objects in the list, e.g., first in first out (FIFO) or alphabetical. The stream of binary data is written to a shared binary file on a shared location accessible by all nodes and/or virtual machines (VMs) of the node cluster. The shared binary file is saved with a filename according to a naming convention or the name may be generated by a random name generator and the file name and shared location is broadcasted to one or more rollover modules of one or more virtual machines in the hypervisor cluster. The one or more rollover modules of the one or more virtual machines de-serialize the binary file and recreate the list of one or more live objects. The one or more rollover modules of the one or more virtual machines perform a rollover operation in parallel based on the one or more live objects. The live object may be information that enables a parallel data rollover by backup proxies, such as a data object of VM configurations and VHD information metadata.

In one embodiment, a snapshot module of a node in a node cluster initializes a backup process. The snapshot module performs a snapshot process to collect virtual machine configurations of each of the virtual machines, and virtual hard disk (VHD) information of the virtual machines of the hypervisor cluster. The snapshot module saves the collected configuration information on a shared binary file in a shared location. The snapshot module determines a list of one or more virtual machines from the virtual machines in the hypervisor cluster to perform a rollover process. The snapshot module sends a federated job or commands to the one or more virtual machines with information about the shared binary file to allow the one or more virtual machines to perform a backup rollover process in parallel. The rollover process may include a sending of storage volume snapshot metadata, the VM configurations, and VHD information to a backup system.

FIG. 1is a block diagram illustrating a storage system according to one embodiment of the invention. Referring toFIG. 1, system100includes, but is not limited to, one or more client systems101-102communicatively coupled to storage system104over network103. Clients101-102may be any type of clients such as a host or server, a personal computer (e.g., desktops, laptops, and tablets), a “thin” client, a personal digital assistant (PDA), a Web enabled appliance, or a mobile phone (e.g., Smartphone), etc. Alternatively, any of clients101-102may be a primary storage system (e.g., local data center) that provides storage to other local clients, which may periodically back up the content stored therein to a backup storage system (e.g., a disaster recovery site or system), such as storage system104. Network103may be any type of networks such as a local area network (LAN), a wide area network (WAN) such as the Internet, a fiber network, a storage network, or a combination thereof, wired or wireless. Clients101-102may be in physical proximity or may be physically remote from one another. Storage system104may be located in proximity to one, both, or neither of clients101-102.

Storage system104may include or represent any type of servers or a cluster of one or more servers (e.g., cloud servers). For example, storage system104may be a storage server used for various different purposes, such as to provide multiple users or client systems with access to shared data and/or to back up (or restore) data (e.g., mission critical data). Storage system104may provide storage services to clients or users via a variety of access interfaces and/or protocols such as file-based access protocols and block-based access protocols. The file-based access protocols may include the network file system (NFS) protocol, common Internet file system (CIFS) protocol, and direct access file system protocol, etc. The block-based access protocols may include the small computer system interface (SCSI) protocols, Internet SCSI or iSCSI, and Fibre channel (FC) protocol, etc. Storage system104may further provide storage services via an object-based protocol and Hadoop distributed file system (HDFS) protocol.

In one embodiment, storage system104includes, but is not limited to, storage service engine106(also referred to as service logic, service module, or service unit, which may be implemented in software, hardware, or a combination thereof), and one or more storage units or devices108-109communicatively coupled to each other. Storage service engine106may represent any storage service related components configured or adapted to provide storage services (e.g., storage as a service) to a variety of clients using any of the access protocols set forth above. For example, storage service engine106may include backup logic121and restore logic122. Backup logic121is configured to receive and back up data from a client (e.g., clients101-102) and to store the backup data in any one or more of storage units108-109. Restore logic122is configured to retrieve and restore backup data from any one or more of storage units108-109back to a client (e.g., clients101-102).

Storage units108-109may be implemented locally (e.g., single node operating environment) or remotely (e.g., multi-node operating environment) via interconnect120, which may be a bus and/or a network (e.g., a storage network or a network similar to network103). Storage units108-109may include a single storage device such as a hard disk, a tape drive, a semiconductor memory, multiple storage devices such as a redundant array system (e.g., a redundant array of independent disks (RAID)), a system for storage such as a library system or network attached storage system, or any other appropriate storage device or system. Some of storage units108-109may be located locally or remotely accessible over a network.

In some embodiments, metadata110-111, may be stored in at least some of storage units108-109, such that files can be accessed independent of another storage unit. Metadata of each storage unit includes enough information to provide access to the files it contains. The metadata may include fingerprints contained within data objects112-113, where a data object may represent a live object or a list of live objects of virtual machine configurations and virtual hard disk information. Fingerprints are mapped to a particular data object via metadata110-111, which enable the system to identify the location of the data object containing a chunk represented by a particular fingerprint.

In one embodiment, storage system104further includes a storage manager or storage controller (not shown) configured to manage storage resources of storage system104, such as, for example, storage space and processing resources (e.g., processor, memory, network resources). The storage manager or controller may be accessed by an administrator of management console or server160remotely via a management or configuration interface (not shown). The administrator can provision and manage storage resources based on a set of policies, rules, and/or service level agreements. The storage resources may be virtualized into a pool of virtual storage resources, where underlying physical storage resources represented by the corresponding virtual storage resources may be implemented locally, remotely (e.g., hosted by another storage system), or both. The virtual storage resources can be provisioned, allocated, and/or defined by an administrator or automatically by the storage manager based on a set of software-defined policies. The virtual storage resources may be represented in one or more virtual machines (e.g., virtual storage systems) managed by one or more virtual machine managers (VMMs). Each of the virtual machines can be provisioned to provide a particular type of storage services (e.g., file-based, block-based, object-based, or HDFS) to a client based on a storage policy or service level agreement associated with that particular client as part of software-defined storage services.

FIG. 2Ais a block diagram illustrating a federated backup environment according to one embodiment of the invention. Node201,202may be representative of client101,102ofFIG. 1, respectively, and backup system205may be representative of storage system104ofFIG. 1. Virtual hard disk (VHD)231,232, and CSV snapshots235in the cluster storage volume (CSV)230may be remote or local, and may be managed by management console/server160ofFIG. 1.

Although only three nodes, node201,202, and203, are shown inFIG. 2A, the federated backup environment or cluster200may include 64, 128, or any number of nodes supported by a federated backup environment. Similarly, node201is showed to include VM211and212, however, node201, and similar nodes, may include any number of virtual machines or VMs supported by a federated backup environment. Each node within cluster200may access CSV230for read and write operations. Furthermore, VMs can migrate from one node to another, such that VMs have complete mobility throughout the cluster as any node can be the VM owner, and the VMs can failover from one node to another seamlessly. Cluster200may deploy the VMs, storage resources and services by a Microsoft virtual machine manager (VMM) or any other type of VMM. VM211, and similar VMs, may run on any operating systems, such as Windows, Mac OS, Linux, or Unix.

Referring toFIG. 2A, Node203contains a Snapshot Module225. Snapshot Module225performs a snapshot process, i.e., to make a photocopy of the cluster shared volume or CSV for a consistent point in time, to generate CSV Snapshots235, and collects VM configurations metadata for all VMs residing on cluster200and VHD information metadata with respect to the VMs. Examples of VM configurations metadata may include metadata of network and DVD configurations of a respective VM. VM configuration metadata may further contain file path of VHDs, path of check-point files. VHD information metadata may include VHD controller metadata, VHD type metadata, and VHD size metadata, of a respective VM. VHD controller metadata describes the VHD controller, i.e., small computer system interface (SCSI), or Integrated Drive Electronics (IDE) disk. Examples of VHD type metadata includes fixed, dynamically expanding, or differencing VHD. Example of VHD size metadata may be 1.0 terabyte. Snapshot module225serializes the collected VM configurations and VHD information metadata, or live objects, and writes the serialized binary data into a binary file on a shared location accessible by all nodes and/or VMs of cluster200. The shared binary file filename may be predetermined or randomly generated by a random filename generated. The shared location may be predetermined or the shared location folder may be created on runtime by snapshot module225. Once a binary shared file is created, snapshot module225or node201may call a federated job or a command line subroutine, with information about the shared binary file as input parameters, to start child processes for a parallel backup rollover operation.

Referring toFIG. 2A, a rollover process may be performed by rollover modules221,222,225of VMs212,214,216respectively. Although this example embodiment ofFIG. 2Ashows three rollover modules on three VMs respectively, a federated backup environment or cluster200may include any number of rollover modules/VMs. Rollover module221-223each receives the federated job or command line call from snapshot module225. Rollover module221-223each retrieves the shared binary file and de-serializes the serialized binary data to reconstruct the live objects, or VM configurations and VHD information metadata representative of all the VMs of cluster200. Rollover module221,222,223processes the live objects to determine which live objects metadata and/or portions of CSV snapshots235to backup, and where it should backup to. VM212,214,216may be grouped to use a load balancer such that rollover modules221-223may rollover, or send, in parallel, the live object and CSV snapshots235metadata to backup system205for a high throughput. Each of the rollover modules221-223may send a separate one of the objects or a segment of an object in a distributed manner.

FIG. 2Bis an object diagram illustrating a live object, according to one embodiment of the invention. Live object250includes a VM backup class object250. VM backup class object250implements a serialize and a de-serialize subroutine. VM backup class object250contains VM configuration class object252and one or more virtual hard disk class objects253each implementing a serialize and a de-serialize subroutine. For example, a call to the serialize subroutine of VM backup class object250may call the serialize subroutine of VM config class252and one or more serialize subroutines of the one or more hard disk objects253, respectively. The serialize subroutine of VM config class252may collect and serialize live objects of VM configuration, such as DVD and network configurations, into binary data. The serialize subroutines of VHD class253may collect and serialize live objects of VHD information of the one or more VMs, respectively, into binary data. The serialize subroutines of VM config class252and VHD class253may pass the serialized binary data as return value to serialize subroutine of VM backup class251. Serialize subroutine of VM backup class251may then return a binary data, representative of the VM backup class object251, to a caller processor. The VHD class253binary data may be ordered according to its occurrence, such an example ordering may be alphabetical. The binary data representative of VM backup class object251may then be exchanged or communicated to other processors in a federated backup environment.

FIG. 3is a flow diagram illustrating a process to use multiple virtual proxies (i.e., VMs) in a federated backup environment to send data to a backup storage, according to one embodiment of the invention. Process300may be performed by processing logic that includes hardware (e.g. circuitry, dedicated logic, etc.), software (e.g., embodied on a non-transitory computer readable medium), or a combination thereof. For example, process300may be performed by node201or snapshot module225of node201ofFIG. 2A. Referring toFIG. 3, at block301, processing logic initializes a backup process on a physical node of a node cluster, such that the node cluster includes a plurality of nodes, each node having one or more VMs. At block302, processing logic executes a snapshot process to capture a snapshot including one or more live objects, such that the live objects comprises VM configurations and virtual hard disk (VHD) information of one or more VHDs, wherein the snapshot represents a consistent point of the node cluster. At block303, processing logic selects a list of one or more virtual machines from the VMs of the one or more nodes of the node cluster. At block304, processing logic transmits the live objects to the list of selected VMs for a data rollover process. At block305, processing logic executes a data rollover process in each of the selected VMs to back up data associated with the live objects to a remote backup system in parallel.

In one embodiment, at least two of the selected virtual machines for the data rollover process are hosted in different nodes of the node cluster. In another embodiment, the snapshot process and the data rollover process is hosted on the same node of the node cluster.

In one embodiment, the snapshot process serializes the live objects into one or more streams of one or more serialized objects, wherein the stream of serialized objects are transmitted from the snapshot process to a data rollover process of each of the selected VMs. In another embodiment, the snapshot process is executed within a host operating system (OS) and each of the rollover processes is executed within a guest OS running in each of the selected VMs. In another embodiment, at least one of the guest OSs of the selected VMs is different than the host OS.

In one embodiment, for each of the serialized objects received at a VM from the snapshot process, a rollover process is executed within the VM deserializing a serialized object to recover a corresponding live object, such that the recovered live object is backed up to a remote backup system. In another embodiment, each of the live object to be backed up is a class object such that the class of the live object implements a serialize function and a deserialize function as function members of the corresponding live object, such that serializing and deserializing are performed by calling the corresponding serialize and deserialize function respectively. Since a host OS and a guest OS may be different, a conventional inter-process communication may not work because they are related to different platforms. By serializing the objects into a binary file, the binary file can be communicated across different platforms more efficiently. A rollover process can simply process the deserialization of the objects without having to worry about the specific platform related features or characteristics of the objects.

FIG. 4is a flow diagram illustrating a sender process400creating a shared binary file in a shared location, according to one embodiment of the invention. Sender process400may be performed by processing logic that includes hardware (e.g. circuitry, dedicated logic, etc.), software (e.g., embodied on a non-transitory computer readable medium), or a combination thereof. For example, process400may be performed by snapshot module225ofFIG. 2A. Referring toFIG. 4, at block401, processing logic creates a shared binary file and/or a shared file folder in a shared location, if a shared binary file and/or shared file folder do not already exist. At block402, processing logic opens the shared binary file for write access. At block403, processing logic serializes a list of predetermined live objects, i.e., VM configurations and VHD information, into a stream of binary data according to its occurrence in the list. The ordering or occurrence may be any ordering such as alphabetical or FIFO. At block404, processing logic writes the stream of binary data into the shared binary file at the shared file folder. At block405, processing logic saves the binary file and sends the binary filename and the shared location via command line or a federated job to a receiver process, such as a receiver process ofFIG. 5, to start a rollover process.

FIG. 5is a flow diagram illustrating a receiver process500receiving a shared binary file and a shared location, according to one embodiment of the invention. Receiver process500may be performed by processing logic that includes hardware (e.g. circuitry, dedicated logic, etc.), software (e.g., embodied on a non-transitory computer readable medium), or a combination thereof. For example, process500may be performed by rollover module221,222,223ofFIG. 2A. Referring toFIG. 5, at block501, processing logic receive a shared filename and a shared location via command line or a federated job. At block502, processing logic opens the shared binary file from the shared location. At block503, processing logic, de-serializes the binary data stream representing a list of live objects to reconstruct the list of live objects. At block504, processing logic reconstructs the list of live objects representing the VM configurations and VHD information to allow the one or more VMs to back up data to a backup system.

FIG. 6is a flow diagram illustrating a serialize process600that serializes an object of backup VM class251ofFIG. 2B, according to one embodiment of the invention. Serialize process600may be performed by processing logic that includes hardware (e.g. circuitry, dedicated logic, etc.), software (e.g., embodied on a non-transitory computer readable medium), or a combination thereof. For example, serialize process600may be performed by node201or snapshot module225ofFIG. 2A. Referring toFIG. 6, at block601, processing logic determines a plurality of VMs of the cluster. At block602, for each of the VMs, processing logic serializes a VM configuration metadata object. At block603, processing logic writes the serialized configuration metadata objects to a shared binary file. At block604, processing logic determines one or more VHDs associated with each of the VMs. At block605, for each of the VHDs associated with each of the VMs, process logic serializes the VHD information metadata objects. At block606, processing logic writes the serialized VHD metadata objects to the shared binary file.

By using the above live object communication for Windows Hyper-V cluster protection, multiple Windows or Linux VMs or a mix of them can be used to send data to backup storage system in parallel. This helps customers or vendors to utilize VMs from any operating systems to perform a data rollover operation. Note that the communication of live objects as described above is not limited to a federated backup environment but may be implemented on a server-client workflow, or a client to client workflow.

Processing module/unit/logic1528, components and other features described herein can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, processing module/unit/logic1528can be implemented as firmware or functional circuitry within hardware devices. Further, processing module/unit/logic1528can be implemented in any combination hardware devices and software components.