Example Architectural Decision – Storage DRS Configuration for NFS Datastores

Problem Statement

In a vSphere environment, a NAS array is presenting Thin Provisioned NFS mounts (Datastores) to the vSphere environment. The storage has deduplication enabled across the datastores being used for the SDRS cluster. What is the most suitable configuration for SDRS to ensure the underlying storage efficiencies are not compromised while maintaining an even distribution of utilized capacity and I/O across all datastores?

Assumptions

1. vSphere 5.0 or later
2. NFS Based storage
3. NFS Mounts (Datastores) are Thin Provisioned
4. Deduplication is enabled on the array
5. VAAI is supported by the array and enabled across the vSphere environment
6. All datastores in a Datastore cluster are of the same RAID Type / Offer Similar performance due to having a similar spindle count
7. All datastores are presented to all hosts within the cluster

Motivation

1. Ensure storage efficiencies are not negatively impacted
2. Minimize the vSphere administrators workload where possible

Architectural Decision

Set the DRS automation setting to “No Automation (Manual Mode)”

  • Set “Utilized Space” threshold to 80%
  • Set “I/O latency” to 15ms
  • I/O Metric Inclution – Enabled

Advanced Options

  • No recommendations until utilization difference between source and destination is: 10%
  • Evaluate I/O load every 8 Hours
  • I/O Imbalance threshold  3

Justification

1. Setting Storage DRS to “No Automation (Manual Mode)” ensures that the administrator can confirm the recommendation will not Negatively impact the efficiency of Deduplication or  the thin provisioned NFS mounts
2. When creating a new Virtual Machine, in the “Ready to complete” window, Tick the “Show all storage recommendations” check box to review Storage DRS recommendations and override the recommendations where required
3. Where a VM is deduplicated on the source datastore, and it is moved to the destination datastore, this write activity is considered new data which will scanned by the post deduplication process which will use valuable CPU cycles on the array
4. “XCOPY” is not supported for NFS, as such, any Storage vMotion activity can only be offloaded to the array using the “Full File Clone” when a virtual machine is powered off.
5. Array level snapshots cannot be migrated with the VM using Storage DRS. If Virtual machines were automatically moved then the array level snapshot relasionship with the VM is broken and it cannot be leveraged
6. NFS datastores can be set to autogrow  by a predefined size in the event they reach a predefined utilization threashold
7. Where a significant I/O imbalance is detected by SDRS, the vSphere administrator can consider the impact of the Storage vMotion and where suitable apply the SDRS recommendation
8. SDRS still provides valuable “initial placement” for new virtual machines which will help avoid a situation where datastores are unevenly balanced from a capacity perspective
9. Storage DRS will still analysis I/O and where an imbalance is identified the vSphere administrator can choose to apply the SDRS recommendation to address the I/O imbalance

Implications

1. When selecting datastores for the datastore cluster, having VASA enabled allows the “System Capability” column to be populated in the “New Datastore Cluster” wizard to ensure suitable datastores of similar performance, RAID type and features are grouped together
2. A vSphere administrator will need to review SDRS recommendations

Alternatives

1. Use “Fully Automated”

A Present from VMware

Recently the number of VMware Certified Design eXperts (VCDXs) passed the 100 mark and to celebrate the wonderful VMware Education team decided to treat all VCDX’s.

Below are some photo’s of what I received late december which included

* A 6 pack of VCDX branded “Special Ale”
* A VCDX branded cooler bag
* Two VCDX Glasses
* A VCDX Sweater custom embroidered with my VCDX Number (#90)
* A VCDX polo shirt
* A HD Camcorder engraved with my VCDX number
* A Leeman Binder with my initials (see picture at bottom of this post)

and my favorite, a Vase with the VCDX logo along with my name and VCDX number on the base.

So just wanted to give a big Thank You to Mark Brunstad (@MarkBrunstad) and the VMware Education team for putting together this package for the VCDXs, I personally greatly appreciate it and you can rest assured the “special ale” did not see out 2012 🙂

Example Architectural Decision – Time Synchronization for Virtual Machines

Problem Statement

What is the best way to keep time synchronized within virtual machine guest operating systems?

Assumptions

1. ESXi hosts are using an accurate and reliable NTP server
2. A level of CPU overcommitment exists in the vSphere cluster

Motivation

1. Prevent the unlikely but possible event of CPU over commitment introducing time drift into guest operating systems

Architectural Decision

Do not use VMware Tools for Time Synchronization Source for Virtual Machines and Guest operating systems need to be configured to use an NTP server

Justification

1. Excessive overcommitment can cause timekeeping drift at rates that are uncorrectable by time synchronization utilities
2. This ensures time within virtual machines is not impacted by time drift in the event of CPU overcommitment
3. Ensure time will be consistent and provided by a central source for all virtual machines
4. NTP is a industry standard method of maintaining accurate time
5. Simplifies the process of maintaining time
6. Aviods the potential issue where Time runs too fast in a Windows virtual machine when the Multimedia Timer interface is usedSee VMware KB 1005953

Implications

1. Any/all templates need to be configured to use an NTP server within the guest operating system
2. All existing servers will need to be updated to use an NTP server within the guest operating system if they currently rely on the hypervisor (VMware Tools) for time

Alternatives

1. Use VMware Tools for time synchronization