This list describes terms and concepts important to understanding the configuration and operation of JetStream DR software.

Concept

Description

Protected Site

The “original” or primary environment where the VMs to be protected normally run.

Recovery Site

The “new” environment where protected VMs will be rehydrated from the object store and run.

Storage Site / Object Store

The storage site is the environment where the object store maintains continuously updated storage objects containing protected VMs and their data. The storage site can be located at the recovery site, or it can be in a different location.

Protected Domain
(a.k.a. “Domain”)

A group of VMs that should be protected and restored together. All VMs in a protected domain are replicated to the same container of the storage site.

Failover

The process where protected VMs and data are retrieved from the storage site and rehydrated at the recovery site. Operation continues from the recovery site.

Failback

The process where protected VMs and data are returned from the recovery site back to the protected site. Operation is shifted back to the protected site.

Continuous Failover
(a.k.a. "CFO")

Continuous Failover is a mode of operation where the protected and recovery sites remain synchronized during normal operation to minimize the amount time necessary to complete DR recovery.

Point in Time Recovery (a.k.a. PITR)

Point-in-Time Recovery allows VMs and data from a particular time in the past (last "known good" point) to be recovered, tested, and then restored. Protected domains can be constructed with PITR capability allowing their VMs and data to be restored to a previous point in time within a window of protection specified by the user.

Management Server Appliance (a.k.a. “MSA”)

The MSA is a virtual appliance that runs as a plug-in to vCenter Server. It collects and maintains statistics relevant to the protection of the VMs in the cluster(s) managed through vCenter. It also provides administrative functions, such as selecting VMs for protection, etc. The MSA can be managed using the vSphere Web Client, and its functions can also be accessed directly via CLI or RESTful APIs.

IO Filter

A “filter” that runs in ESXi and provides direct access to the IO path between a VM and its corresponding virtual disk(s). IO Filters monitor relevant events, such as vMotion, Storage vMotion, snapshots, etc. and manage the flow of data between protected VMs and storage.

DR Virtual Appliance
(a.k.a. “DRVA”)

While the IO Filters capture data for replication, they do not communicate directly with the object store. The DRVA is a virtual appliance that maintains the replication log store and manages the transfer of the VMs and their data to the object store. The DRVA also manages functions such as in-line compression and garbage collection. There must be at least one DRVA per protected cluster, and there can be up to one DRVA per host.

Recovery from Object Cloud Virtual Appliance (a.k.a. RocVA)

A virtual appliance that is deployed for recovery, failover, and failback. During a recovery process, the RocVA runs temporarily to facilitate the rehydration of the VMs and their data from the object store. The RocVA is automatically removed at the conclusion of the process.

Representation VM
(a.k.a. RVM)

During failover, an RVM is created for each VM being rehydrated. RVMs are temporary. They are created during the recovery process (failover, failback, restore) and are automatically deleted when no longer needed.

Replication Log

The replication log is the record of data being replicated to the object store. Each protected domain uses a single replication log for all the VMs belonging to the protected domain.

Replication Log Volume

The shared non-volatile memory resource in the protected site that is dedicated for the use of JetStream DR software. Exposed to the DRVA(s) as an iSCSI LUN, or VMDK-based virtual disk, the replication log volume is used to maintain replication logs as well as garbage collection metadata and other metadata created by the JetStream DR software.

Background Replication

The process of reading existing data from the virtual disk at the protected site and copying it to the object store. Background replication is important especially when protection is initiated.

Foreground Replication

The process of continuously identifying newly generated data at the protected site and copying it to the appropriate object store destination. 

Write Throttling (Backpressure)

Controlled slowing of an application’s write operations at the protected site, typically when network bandwidth is insufficient for the amount of foreground replication induced by the application’s current write activity.

Replication Rate (Backpressure)

Controlled slowing of background replication to avoid negatively impacting application performance.

Garbage Collection

The process in which invalidated data that is no longer needed at the protected site is removed from the object store. This minimizes unnecessary consumption of storage space at the object storage site.

Runbook

A set of instructions that are followed as part of failover or failback to specify VM startup sequence and configuration parameters for a protected domain.

Protection Modes

Two methods are available to write protected data to primary storage and the replication log. (1) “Write-through” method: The IO Filter acknowledges completion of a write operation back to a protected VM only after it has received acknowledgement of the write from both the replication log and the primary storage. (2) “Write-back” method: The IO Filter acknowledges completion of the write operation to the protected VM upon receiving acknowledgement from the replication log volume only; the write to primary storage is asynchronous.

Ownership (IO Fencing)

To maintain integrity of a protected domain, only one JSDR site at a time can write (update) the object store for a domain. Multiple sites can connect to the protected domain to read the contents and status, but only the owning site DRVA can write to the protected domain's container in the object store. The DRVA on the "owning" site updates domain status to maintain ownership and maintain the write lock (fencing out other site's DRVA from writing).

Ownership of the protected domain can shift between the local protected site or the remote recovery site depending upon the action currently being performed.