09.03.2015 Views

VSAN-Troubleshooting-Reference-Manual

VSAN-Troubleshooting-Reference-Manual

VSAN-Troubleshooting-Reference-Manual

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!