If you want to perform replication tasks with your VA, you need to add a second “scratch” disk to the VA. This scratch disk is used to store two types of files:
• vzmap files: Block maps — in the form of a vzmap file — for the VMs replicated to the destination host. This file contains block map information, and not actual data blocks. These maps are compared to the source VM during each replication to identify the data blocks that have changed since the last replication. The vzmap files make differential replication faster as they remove the need to scan the destination VM blocks for comparison with the source VM.
• vzUndo files: As data is sent to the destination host, by using the VA, blocks in the destination disk are written to the undo file before they are overwritten by the changed data. If replication fails and an undo becomes necessary, the original destination disk blocks are read from the undo file and written to the destination disk to roll back the failed replication. This process is a key function designed to provide resiliency in the face of a network failure; if there is a network failure during the replication pass, the destination VM is not corrupted by incomplete data.After the replication is complete, and all data has been received by the destination VA, the undo file is deleted. At that point, the storage space used by the undo file is returned to the VA for use. Undo files are not created during the first replication. During the first replication, the entire VM is sent to the destination host, but there is no existing data on the destination VMDKs, and therefore no risk of corruption. Data is streamed directly to the VMDK. You do not need to allocate scratch disk space for this scenario.While the vzmap files are trivial in size, in the order of a few MB, the undo file can potentially be as large as the VM itself. While the scratch disk needs to be configured to a size sufficient to handle the data of concurrent replication tasks, making it too large wastes valuable storage space. Use the following topics to guide you in determining the proper size for the scratch disk.The scratch disk needs to be large enough only to hold the permanent vzmap files and the temporary vzUndo files, plus a small margin for safety. How large that is depends almost entirely on the amount of changed data you are replicating. The amount of changed data is itself a function of the number of VMs you are replicating, their total disk size, replication frequency, and the data change rate per VM. It is important to understand all this data when sizing the scratch disk.If you are using one VA for a cluster, remember that you must account for all simultaneous replications for the cluster.If you have previously replicated the source VMs, the most accurate method to size the scratch disk properly, without wasting storage space, is to use historical replication data. This data is available in the Replicate Task Reports, in the vRanger My Reports view, for the applicable VMs. This report shows the amount of data written during each replication task.The safest method to size your scratch disk based on historical data is to record the highest amount of data written for each VM that you replicate at one time, and size the disk to accommodate those values.To avoid filling your scratch disk, Quest recommends that you add a small margin, 10% or so, to the calculated scratch disk size for safety.If you do not have information on the amount of changed data for each VM, you can estimate the appropriate size of the scratch disk based on the VM size and the number of VMs you plan to replicate at one time.A general rule for sizing the scratch disk is to choose a percentage of the total VM size to represent the practical limit of changed data for a given replication. Only you can decide what is appropriate for your environment. The following numbers are examples given to illustrate the concept:For example, if you have four VMs that you want to replicate to a host or cluster at the same time, the minimum requirements for the VMs are described in the following table.
Table 2. Minimum requirements For the preceding VMs, you would need approximately 48 GB of disk space for the undo files, plus a buffer of approximately 10%, for safety’s sake. In the example, an appropriate estimate for the scratch disk size for the preceding VMs would be approximately 55 GB.Bear in mind that the estimate exercise should be done for every set of VMs you want replicated to that host or cluster, with the scratch disk being sized to accommodate the largest value obtained.
As previously stated, the primary driver for the scratch disk size is the amount of changed data that needs to be replicated. If you need to reduce the storage requirements for your scratch disk, you can:
• Reduce the number of VMs that you replicate simultaneously. Doing so sends less data through the scratch disk at any one time, which requires less space. Remember that the vzundo files are deleted after the replication completes.
• As the scratch disk is used primarily for staging changes before they are written to disk — activity which occurs on the destination host or cluster — the scratch disk on the source side can be kept fairly small. However, in case you need to fail over to the disaster recovery (DR) site, the replication job reverses direction and starts replicating changes back to the product site — the original source host or cluster. For this process to occur, the scratch disk on the source side needs to be re-sized to accommodate the changed data.When creating the second disk, make sure that you place the disk on a datastore with block sizes large enough to support the expected VMDK. The following list shows the maximum file size available for each block size:
vRanger uses a virtual appliance (VA) for replication to and from VMware® ESXi™ hosts, for FLR from Linux® machines, and optionally for backups and restores. The VA Deployment Wizard offers a simple method to deploy VAs one at a time. You can run the wizard for each VA that you need to deploy, or alternatively deploy multiple VAs at once as described in About deploying multiple VAs.
▪ In the Tools menu, click Virtual Appliance Deployment Wizard.
▪ In the My Inventory view, right-click the host to which the VA should be deployed, and click Deploy Virtual Appliance.
▪ In the Virtual Appliance Configuration node of the Configuration Options dialog box, click Deploy Virtual Appliance.
2 When the Virtual Appliance Deployment Wizard appears, click Next.You may deploy a VA to a single host or to a cluster. When performing a backup, restore, or replication task, vRanger first checks for a VA on the host. If no VA is associated with the host, and if the host is part of a cluster, vRanger checks for a VA on the cluster.
1 Select Deploy VA on Cluster.
3 Select Deploy VA on specific host.
5 Click Next.In the VA Deployment Options dialog box, you can configure the VA’s name and allocated resources. Also, you can configure the size of the VA’s scratch disk. For more information, see The VA scratch disk.
1 In the Virtual Appliance Properties section, confirm the VA Name — edit as required.
2 In the Virtual Appliance Option section, configure the resources allocated to the VA.
▪ Minimum Required: This setting allocates one CPU and 512 MB of RAM. This entry is sufficient for two concurrent tasks per VA.
▪ Quest Recommended: This setting allocates two CPUs and 1 GB of RAM. This entry is sufficient for four concurrent tasks per VA.
▪ Quest Recommended (with RDA repository): This setting allocates four CPUs and 2 GB of RAM. This entry is sufficient for running tasks going to RDA repositories.
▪ Custom Setting: Select this value to configure the VA with higher resources for five or more concurrent tasks per VA.
3 In the VA Datastore field, select the datastore for the VA’s primary disk.
4 In the Network Assignment field, select the network for the VA’s primary NIC.
5 Select Use this virtual appliance for replication and configure the scratch disk size and datastore location. Use the information in Strategies for sizing the scratch disk to guide you.
NOTE: If you are upgrading an existing VA and want to migrate the scratch disk, do not select this option. For more information, see the topic on upgrading the vRanger VA in the Quest vRanger Installation/Upgrade Guide.
▪ In the VA Password and Confirm password field, enter a new password for the VA. If you change the password, this password becomes the default for subsequent VA deployments performed during this session.
▪ Leave the default password of vzroot1.
NOTE: You may change the password in the future as described in Changing the VA configuration.
7 If you want to perform FLR from backups of Linux® VMs, configure a VA to use for Linux FLR.Select Use virtual appliance for Linux File Level Restore.On the VA IP Address Configuration page, you must configure the network configuration for the VA’s primary network interface card (NIC).
▪ Use DHCP for IP assignment automatically assigns IP settings to the VA if a DHCP server is available.
▪ Use Static IP lets you deploy the VA with a manual IP configuration.
▪ Obtain the DNS server address automatically uses the DNS settings provided by your DHCP server.
▪ Use the following DNS server address lets you specify DNS settings manually.
3 Click Next.Complete the steps in the following procedure to confirm the VA deployment options displayed are correct.
1 If the configuration options are not correct, click Back to change to the information.
2 [Optional] Select the option to Power on the VA after deployment is complete, and then see Creating a template.Optionally, if you need to deploy the vRanger VA to multiple hosts, it may be helpful to create a VM template from the configured VA.
1 From the VI Client, right-click the configured VA, select Template, and then click Clone to Template.
5 In the Disk Format dialog box, select Same format as source, and click Next.
The VA must be deployed to any VMware® ESXi™ host that you want to configure for replication — either as a source or a destination. For hosts in a cluster, you may deploy the VA to just one host in the cluster; the VA is shared among the cluster’s hosts.In addition, replication by way of a VA requires that if a VA is used on one host or cluster in a replication job, a VA must be used on both the source and destination host or cluster. In other words, VAs, when used for replication, must be used in pairs.For a few VAs, using the vRanger UI to deploy the VAs is sufficient. To streamline the process of deploying a high number of VAs, Quest recommends that you deploy and configure the VA once, and save it as a template to be used for additional deployments using the VMware vSphere® PowerCLI™. The Creating a template procedures include an optional step for creating a template from the configured VA.
▪ In the My Inventory view, right-click the VA you want to change, and then click Virtual Appliance Configuration.
a Click Tools, and then click Options.
b In the Configuration Options dialog box, select Virtual Appliance.
c Under Configure Existing Virtual Appliances, select the VA to change, and then click Edit.The Modify Virtual Appliance Configuration dialog box appears.
2 In the Virtual Appliance Properties section, do the following:
a Next to VA Name, confirm the name of the VA.
b Next to IP Address, confirm the IP vRanger uses to connect to the VA.By default, vRanger connects to the vRanger VA using the first IP address reported by the VMware vSphere® API. This IP is displayed under Virtual Appliance Properties in the IP Address field. If you have only one NIC configured on the VA, continue to the next step.If you have more than one NIC configured on the VA, you may not want vRanger to connect to the first NIC. Select Override IP Address to configure vRanger with the IP address for the NIC to which vRanger should connect.For example, if you have two NICs configured on the VA, and want vRanger to connect to the second NIC, select Override IP Address to enable the IP Address field, and then enter the IP for the second NIC in the IP Address field.
NOTE: For information about manual network configuration procedures, see Configuring VA networking.
3 In the Virtual Appliance Options section, use the Select an option drop-down list to change the resources allocated to the VA as needed.
▪ Minimum Requirement: This setting allocates one CPU and 512 MB of RAM. This entry is sufficient for two concurrent tasks per VA.
▪ Quest Recommended: This setting allocates two CPUs and 1 GB of RAM. This entry is sufficient for four concurrent tasks per VA.
▪ Custom Setting: Select this value to configure the VA with your own preferred settings; for example, higher resources for more concurrent tasks per VA.
4 To change the datastore for the VA’s primary disk, select the new datastore from the VA Datastore drop-down list.
NOTE: If you are using a VMware® vCenter™ version lower than 5.0, the ability to change the datastore of the VA scratch disk used for replication is not available.
5 Select Use this virtual appliance for replication and configure the scratch disk size using the up-and-down arrows and the drop-down list. For more information about sizing a scratch disk, see Strategies for sizing the scratch disk.
6 [Optional] Enter a new password for the VA in the VA Password field, and then re-enter it in the Confirm password field.
7 If you want to perform FLR from backups of Linux® VMs, select Use virtual appliance for Linux File Level Restore to configure a VA to use for Linux FLR.
© 2020 Quest Software Inc. ALL RIGHTS RESERVED. Feedback 利用規約 プライバシー