Good Read: Virtual SAN data locality white paper

2 Comments

I was reading the Virtual SAN Data Locality white paper. I think it is a well written paper, and really enjoyed it. I figured I would share the link with all of you and provide a short summary. (http://blogs.vmware.com/vsphere/files/2014/07/Understanding-Data-Locality-in-VMware-Virtual-SAN-Ver1.0.pdf)

The paper starts with an explanation of what data locality is (also referred to as “locality of reference”), and explains the different types of latency experienced in Server SAN solutions (network, SSD). It then explains how Virtual SAN caching works, how locality of reference is implemented within VSAN and also how VSAN does not move data around because of the high cost compared to the benefit for VSAN. It also demonstrates how VSAN delivers consistent performance, even without a local read cache. The key word here is consistent performance, something that is not in the case for all Server SAN solutions. In some cases, a significant performance degradation is experienced minutes long after a workload has been migrated. As hopefully all of you know vSphere DRS runs every 5 minutes by default, which means that migrations can and will happen various times a day in most environments. (Seen environments where 30 migrations a day was not uncommon.) The paper then explains where and when data locality can be beneficial, primarily when RAM is used and with specific use cases (like View) and then explains how CBRC aka View Accelerator (in RAM deduplicated read cache) could be used for this purpose. (Does not explain how other Server SAN solutions leverage RAM for local read caching in-depth, but sure those vendors will have more detailed posts on that, which are worth reading!)

Couple of real gems in this paper, which I will probably read a couple of times in the upcoming days!

vSphere 5.5 and disk limits (mClock scheduler caveat)

8 Comments

I mentioned the new disk IO scheduler in vSphere 5.5 yesterday. When discussing this new disk IO scheduler one thing that was brought to my attention is a caveat around disk limits. Lets get started by saying that disk limits are a function of the host local disk scheduler and not, I repeat, not Storage IO Control. This is an often made mistake by many.

Now, when setting a limit on a virtual disk you define a limit in IOPS. The IOPS specified is the maximum number of IOPS the virtual machine can drive. The caveat is is as follows: IOPS takes the IO size in to account. (It does this as a 64KB IO has a different cost than a 4KB IO.) The calculation is in multiples of 32KB. Note that if you do a 4KB IO it is counted as one IO, however if you do a 64KB IO it is counted as two IOs. Any IO larger than 32KB will be 2 IOs at a minimum as it is rounded up.  In other words, a 40KB IO would be 2 IOs and not 1.25 IOs. This also implies that there could be an unexpected result when you have an application doing relatively large blocksize IOs. If you set a limit of 100 IOPS but your app is doing 64KB IOs than you will see your VM being limited to 50 IOPS as each 64KB IO will count as 2 IOs instead of 1. So the formula here is: ceil(IO Size / 32).

I think that is useful to know when you are limiting your virtual machines. Especially cause this is a change in behaviour compared to vSphere 5.1.

Essential Virtual SAN book available as of today! (ebook first)

5 Comments

Yes, the day has finally come… Our pet project, the Essential Virtual SAN book is finally out! Cormac and I decided to take the “e-book first” route which enables us to have it out weeks before the printed copy. Before doing the thank you’s and provide you with some details on what the book is about, I want to thank my co-author Cormac! It was a great pleasure working with you on this project Cormac, thanks for asking me to be part of this exciting book!

We want to thank our technical editors Paudie O’Riordan and Christos Karamanolis, whom spent countless of hours reading and editing our raw materials. We would like to thank the VMware Virtual SAN engineering team for the countless of hours discussing the ins and outs of Virtual SAN. Especially Christian Dickmann and (again) Christos Karamanolis, it would not have been possible without your help! We also want to acknowledge William Lam, Wade Holmes, Rawlinson Rivera, Simon Todd, Alan Renouf, and Jad El-Zein for their help and contributions to the book. Last but not least we want to thank the Pearson team for their flexibility and agility and getting things done, and our management (Phil Weiss, Adam Zimman, and Mornay van der Walt) for supporting us on this journey.!

Cormac and I are also very pleased to say that we have two awesome forewords by no one less than VMware CTO Ben Fathi and SVP of Storage and Availability at VMware Charles Fan! Thanks for taking the time out of your busy schedule, we very much appreciate it.

What does the book cover?

Understand and implement VMware Virtual SAN: the heart of tomorrow’s Software-Defined Datacenter (SDDC)

VMware’s breakthrough Software-Defined Datacenter (SDDC) initiative can help you virtualize your entire datacenter: compute, storage, networks, and associated services. Central to SDDC is VMware Virtual SAN (VSAN): a fully distributed storage architecture seamlessly integrated into the hypervisor and capable of scaling to meet any enterprise storage requirement.

Now, the leaders of VMware’s wildly popular Virtual SAN previews have written the first authoritative guide to this pivotal technology. You’ll learn what Virtual SAN is, exactly what it offers, how to implement it, and how to maximize its value.

Writing for administrators, consultants, and architects, Cormac Hogan and Duncan Epping show how Virtual SAN implements both object-based storage and a policy platform that simplifies VM storage placement. You’ll learn how Virtual SAN and vSphere work together to dramatically improve resiliency, scale-out storage functionality, and control over QoS.

Both an up-to-the-minute reference and hands-on tutorial, Essential Virtual SAN uses realistic examples to demonstrate Virtual SAN’s most powerful capabilities. You’ll learn how to plan, architect, and deploy Virtual SAN successfully, avoid gotchas, and troubleshoot problems once you’re up and running.

Coverage includes

  • Understanding the key goals and concepts of Software-Defined Storage and Virtual SAN technology
  • Meeting physical and virtual requirements for safe Virtual SAN implementation
  • Installing and configuring Virtual SAN for your unique environment
  • Using Storage Policy Based Management to control availability, performance, and reliability
  • Simplifying deployment with VM Storage Policies
  • Discovering key Virtual SAN architectural details: caching I/O, VASA, witnesses, pass-through RAID, and more
  • Ensuring efficient day-to-day Virtual SAN management and maintenance
  • Interoperating with other VMware features and products
  • Designing and sizing Virtual SAN clusters
  • Troubleshooting, monitoring, and performance optimization

ASIN: B00LODTZSA
ISBN-10: 013385499X
ISBN-13: 978-0133854992

You can buy it via Amazon.com for Kindle, and it will also be available shortly via Pearson.com for any other ebook format!

das.maskCleanShutdownEnabled is set to true by default

Leave a Comment

I had a couple of questions on the topic of das.maskCleanShutdownEnabled today. For those who have not read the other articles I wrote about this topic, this is in short what it does and why it was introduced and how I explained it in an email today:

When a virtual machine is powered off (or shut down) by a user a property is set to true named “runtime.cleanPowerOff”. To vSphere HA this indicates that the virtual machine was powered off by a user and as such when a host fails it knows that for this virtual machine it doesn’t need to take action. By default this property is set to true. If for whatever reason the virtual machine is killed by ESXi than this property is set to false.

vSphere HA provides the ability to respond to a storage failure (PDL). When a PDL occurs it can kill a virtual machine and then restart the virtual machine. However, “runtime.cleanPowerOff” default is “true” and vSphere HA cannot access the datastore (PDL remember) to change the property! So this means if the VM is killed after the PDL, then it won’t be restarted as HA assumes it was cleanly powered off.

This is where das.maskCleanShutdownEnabled comes in to play. By setting this to “true”, vSphere HA assumes that VM is not cleanly powered off. Only when you cleanly power it off the property is set. In other words, In a PDL situation it will now restart the VM even though the datastore was unavailable when the VM was killed!

Back to the original question, what is das.maskCleanShutdownEnabled set to in 5.1 and later? Do you need to set it manually? No you do not, by default it is set to true! So when you configure a cluster, be aware of this… Especially in a stretched cluster environment where a PDL scenario is not unlikely.

** do not forget to also set terminateVMonPDL described in this blog post if you want VMs to be automatically killed when a PDL occurs! **

vSwitch Traffic Shaping, what is what?

Leave a Comment

I was troubleshooting an issue where vMotion would time-out constantly, I had no clue where it was coming from so I started digging. In this case the environment was using a regular vSwitch and 10GbE networking. When I took a closer look I noticed that some form of traffic shaping was applied, as unfortunately the Distributed vSwitch was not an option for this environment. Now traffic shaping was enabled and the peak value was specified and the rest was left to the default value… and unfortunately this is exactly what cause the problem.

So when it comes to vSwitch Traffic Shaping, what is what? There are 3 settings you can set per portgroup:

  • Average Bandwidth – specified in Kbps
  • Peak Bandwidth - specified in Kbps
  • Burst Size - specified in KB

So if you have a 10Gbps NIC port for your traffic this means you have a total of 10,485,760 Kbps. When you enable vSwitch Traffic Shaping by default it is set to have “Average Bandwidth” to 100,000 Kbps , Peak Bandwidth to 100,000 Kbps and Burst Size to 1024,00 KB. So what does that mean? Well it means that if you enable it and do not change the values that the traffic is limited to 100,000 Kbps. 100,000 Kbps is… yes roughly 100Mbps, even less to be more precise: 97.6Mbps. Which is not a lot indeed, and not even a supported configuration for vMotion.

So what if I simply bump up the Peak Bandwidth to lets say 5Gbps, as I do not want vMotion to ever consume more than half of the NIC port (note, vSwitch traffic shaping is only for egress aka outbound traffic). Well setting the peak bandwidth sounds like it may do something, but probably not what you would hope for as this is how the settings are applied:

By default the traffic stream will get what is specified by “Average Bandwidth”. However, it is possible to exceed this when needed by specifying a higher “Peak Bandwidth” value. Your traffic will be allowed to burst until the value of “Burst Size” has been exceeded. In other words, in the above example when only Peak Bandwidth is increased this would lead to the following: By default the traffic is limited to 100Mbps, however it can peak to 5Gbps but only for 100MB worth of data traffic. As you can imagine in the case of vMotion when the full memory content of a VM is transferred that 100MB is hit within a second, after which the vMotion process is throttled back to 100Mbps and the remainder of the VM memory takes ages to copy and eventually times out.

So if you apply traffic shaping using your vSwitch, make sure to think through the numbers. In the above scenario for instance, specifying a 5Gbps Average and Peak would be what was desired.