In order to be able to move Virtual Machines (VMs) from one ESX server to another, the ESX servers must access the same storage devices. The current infrastructure supports the Network File System (NFS). The use of NFS for system disk storage instead of traditional FC/iSCSI storage has resulted in a significant cost savings by simplifying the management of the VSS storage requirements.
The VSS storage configuration is as follows:
- There are two NFS datastores for the storage of VMs residing on the same USG volume but different qtrees. One NFS datastore and qtree for Disaster Recovery (DR) VM and one for non-DR VM. This allows for ease of moving a VM from non-DR storage to DR storage and vice-versa. The qtree that contains the DR VMs will be snapmirrored to the secondary storage.
- The USG volume will be configured to run snapshots that will be snapvaulted to the secondary storage for data protection purposes. 28 days worth of daily snapshots and 12 weeks of weekly snapshots are retained on the secondary store. The USG volume could be configured at your request to make use of auto-grow to dynamically resize the volume on an as-needed basis. Separate data storage on the USG volume may be purchased at your request.
Comparing NFS to VMFS/FC SAN storage
The table compares NFS to VMFS/FC SAN storage and when they are used.
| NFS | VMFS/FC SAN | Description |
|---|---|---|
| x | Provisioning of USG storage is easier and more scalable with NFS than creating and mounting VMFS LUNs. VMFS works well with 20 to 30 VMs, but NFS is much easier and more scalable when you have hundreds or thousands of VMs. | |
| x | Ease and speed for migrating VMs from one USG volume to another. | |
| x | Performance is not limited to a single disk I/O queue. | |
| x | SAN administration overhead is reduced for activities such as configuring FC switches, zones, HBAs and identical LUN IDs across ESX servers. | |
| x | Easier to restore multiple VMs, individual VMs or files within VMs. | |
| x | The volume and the VMDK is thin provisioned resulting in better disk utilization. An on-demand storage utilization model is used so only storage that is actually needed is used. A traditional VMFS volume utilization will be around 70-80% (with the remaining 20-30% essentially unused) and the VMDK itself may be sitting at 70%. The resulting storage utilization is probably only around 49-56%, excluding RAID overhead. | |
| x | Better performance in terms of throughput and latency. Latency in a VM environment is more important than bandwidth given the small, random I/O pattern inherent in a virtual environment. | |
| x | Link aggregation (IEEE 802.3ad - NetApp multimode VIF with IP aliases) can improve overall throughput. | |
| x | Boot for each ESX server blade so an ESX server can be replaced expediently. | |
| x | VMs running Database servers or software that require direct I/O or large amounts of data storage will use Raw Device Maps. | |
| x | Any VM participating in a cluster framework will require access to a quorum drive. |
