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 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.
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:
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.
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.