Before using the vRanger virtual appliance, you will 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 is block map information, and not actual data blocks. These maps are compared to the source VM during each replication pass to identify the data blocks that have changed since the last replication. The vzmap files make differential replication significantly 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 (via 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, then the original destination disk blocks are read from the undo file and written to the destination disk to rollback the failed replication. This 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. |
Once the pass 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. Note that undo files are not created during the first pass of a replication job. During the first pass, 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 MBs), 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 sections below to guide you in determining the proper size for the scratch disk.
Strategies for Sizing 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’ll be replicating, their total disk size, replication frequency, and the data change rate per VM. It is important to understand all of this data when sizing the scratch disk.
Note | There is a limit of four simultaneous replication tasks per VA |
Use Historical Data
If you have previously replicated the source VMs, the most accurate method to properly size the scratch disk (without wasting storage space) is to use historical replication data available in the Replicate Task Reports (in the vRanger My Reports view) for the VMs in question. This report will show 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 will replicate at once, and size the disk to accommodate those values.
To avoid filling your scratch disk, Quest Software recommends that you add a small margin (10% or so) to the calculated scratch disk size for safety.
Calculating
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 will be replicating at once.
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 pass. Only you can decide what is appropriate for your environment. The numbers below are examples given to illustrate the concept:
Assume that you will have four virtual machines that you wish to replicate to a host at the same time. These VMs are described in the table below.
VM | V M Size | ChangeRate | ChangeSize |
1 | 100 GB | 15% | 15 GB |
2 | 100 GB | 10% | 10 GB |
3 | 100 GB | 20% | 20 GB |
4 | 60 GB | 5% | 3 GB |
For the VMs above, we would need approximately 48 GB of disk space for the undo files, plus a buffer of approximately 10% (for safety’s sake). In our example, an appropriate estimate for the scratch disk size for the VMs above would be approximately 55 GB.
Bear in mind that the estimate exercise should be done for every set of VMs that will be replicated to that host, with the scratch disk being sized to accommodate the largest value obtained.
Caution | If the scratch disk runs out of space, replication tasks will fail with the error “FATAL cant_write can't write vix”. |
Options for a Smaller Scratch Disk
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 amount of time that passes between replication intervals. More frequent replication passes will contain smaller amounts of changed data. |
• | reduce the number of VMs that you replicate simultaneously. This will send less data through the scratch disk at any one time, allowing it to be smaller. Remember that the vzundo files are deleted after the replication pass completes. |
• | when provisioning the scratch disk, select the Thin Provisioning option. Thin provisioning helps prevent wasted storage space by not allocating blocks until they are written by the VM. |
The Scratch Disk on the Source Host
As the scratch disk is used primarily for staging changes before they are written to disk – activity which occurs on the destination host – the scratch disk on the source machine can be kept fairly small. However, in the event that you need to fail over to the D/R site, the replication job will reverse direction and start replicating changes back to the product site (the original source host). In order for this to occur, the scratch disk on the source host will need to be re-sized to accommodate the changed data.
Scratch Disk Location
When creating the second disk, make sure you place the disk on a datastore with block sizes large enough to support the expected VMDK. The list below shows the maximum file size available for each block size:
• | 1 MB block size – 256 GB maximum file size |
• | 2 MB block size – 512 GB maximum file size |
• | 4 MB block size – 1024 GB maximum file size |
• | 8 MB block size – 2048 GB maximum file size |
Note | This limitation does not apply to VMFS 5. |