VSAN-Troubleshooting-Reference-Manual
VSAN-Troubleshooting-Reference-Manual
VSAN-Troubleshooting-Reference-Manual
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Diagnostics and <strong>Troubleshooting</strong> <strong>Reference</strong> <strong>Manual</strong> – Virtual SAN<br />
that you have NIOC that will allow you to place Quality Of Service (QoS) on vMotion,<br />
Virtual SAN and other network traffic types.<br />
With this in place, vMotion can run during production hours, and won’t<br />
inadvertently impact Virtual SAN operations.<br />
Virus Scans<br />
From the VMware paper “Antivirus Best Practices for VMware Horizon View 5.x”<br />
which can be found here http://www.vmware.com/files/pdf/VMware-View-<br />
AntiVirusPractices-TN-EN.pdf, the challenge with Virus Scans is most virus scanning<br />
model involves agents executing on every desktop performing antivirus scanning.<br />
During these operations, system resource usage can spike or become overly<br />
committed. Performance is severely impacted by these “antivirus storms.”<br />
Traditional antivirus agents are resource-intensive and antivirus storms can cause<br />
100 percent saturation in the compute and storage (including a Virtual SAN<br />
datastore). In addition, the memory footprint is significant when antivirus software<br />
is installed on each virtual machine.<br />
VMware has solutions to address the “antivirus storm” issue by consolidating and<br />
offloading all antivirus operations into one centralized security virtual appliance.<br />
The whitepaper referenced above has further information.<br />
Notes on using IOmeter with Virtual SAN<br />
Many administrators rely on a tool called IOmeter to do storage performance testing.<br />
This is also true for performance testing on Virtual SAN. When the results of this<br />
testing are not correctly understood, or do not meet expectations, the assumption is<br />
that there is an underlying performance issue with Virtual SAN. This is not<br />
necessarily the case, and more often than not it is how IOmeter has been configured<br />
to run. If the plan is to use IOmeter to test Virtual SAN performance, there are a<br />
number of factors that need consideration.<br />
1. Iometer creates synthetic workloads, not reflective of real-life workloads.<br />
Real life virtual machine workloads do not behave like synthetic IOmeter<br />
workloads. IOmeter workloads tend to be steady state, repeating the<br />
same patterns over and over again. Production workloads are typically<br />
not like that, with peaks and troughs, as well as bursts of traffic.<br />
2. The working set of a VM running IOmeter can be configured to be much,<br />
much larger than a working set of a production VM. IOmeter can consume<br />
a whole VMDK as its working set, which is usually not reflective of<br />
production workloads.<br />
3. Your cache is limited. When using IOmeter consider the working set and<br />
if it fits in cache. Consider a small number of VMs with a large working set<br />
V M W A R E S T O R A G E B U D O C U M E N T A T I O N / 2 5 7