With SRM implementations, there is a common argument about the placement of the virtual machine swap files. Some would suggest maintaining a separate datastore for the virtual machine swap files, whereas some are against it. Before we try to understand the rationale behind these design choices, it is important to know what a virtual machine swap file is.
Every virtual machine will have a swap file (.vswp). This swap file is created every time a virtual machine is powered on. The size of the swap file is equal to the size of the memory assigned to the virtual machine, unless there is a reservation. If there is a memory reservation, then the size of the swap file will be equal to the size of the unreserved memory. Although rare, some environments use limits on memory as well.
So, the ideal formula to calculate the size of the swap file is as follows:
The default memory reservation is 0 MB and the default limit is equal to the configured size of the memory. By default, the swap file is stored along with the virtual machine in its working directory.
Rationale: The swap file is created every time a virtual machine is powered-on. Since the VM will be powered on at the recovery site, and the swap file will be created at that time, there is no need to replicate the swap files.
The following table illustrates the pros and cons of this:
|
Pros |
Cons |
|---|---|
|
Swap file replication, if avoided, can reduce the bandwidth utilization for storage replication. |
Single point of failure. |
|
Reduces the need for the storage space at the recovery site, which otherwise would be needed for the swap files. |
The swap location should be chosen at a per host level. This would require a lot of manual work in a large environment. |
|
Need to accommodate a separate large LUN. This could affect the available spare capacity of the array. |
Rationale: Apart from the reduced replication bandwidth usage, there is no real advantage of maintaining a separate datastore for the swap files, and most SRM implementations would have already made sure that there would be more than enough bandwidth to make storage replication feasible. Also, not all virtual machines frequently use swap the files unless the vSphere environment is oversubscribed and the virtual machines are frequently contending for memory resources. In most cases, the swap files will be replicated during the initial sync. Subsequent synchronizations will include swap files created consequent to power-off and power-on operations. Keep in mind that a Guest OS reboot will not trigger the recreation of the swap files.
|
Pros |
Cons |
|---|---|
|
No administrative overhead, which would otherwise be needed to configure a swap datastore per host |
Bandwidth wastage, due to the replication of the swap files |
|
No single point of failure |
Wasted storage capacity at the recovery site, which could be otherwise avoided if the swap files are not duplicated on the replica LUNs |