Sharing VMUG presentation “vSphere futures”

Last week I presented at the UK VMUG, Nordic VMUG and VMUG Belgium. My topic was vSphere futures… I figured I would share the deck publicly. The deck is based on this blog post and essentially is a collection of what has been revealed at last VMworld. Considering the number of announcements I am guessing that this deck is a nice summary of what is coming, feel free to use it / share it / comment etc.

Once again, I would like to thank the folks of the VMUG organizations throughout EMEA for inviting me, three great events last week with very passionate people. One thing I want to call out in particular that struck me last week: Erik from the VMUG in Belgium has created this charity program where he asks sponsors (and attendees) to contribute to charity. Last event he collected over 8000 euros which went to a local charity, it was the biggest donation that this particular charity received in a long time and you can imagine they were very thankful… all of this while keeping the event free for attendees, great work Erik! Thanks for giving back to the community in various ways.

See you next time.

Validate your hardware configuration when it arrives!

In the last couple of weeks I had 3 different instances of people encountering weird behaviour in their environment. In two cases it was a VSAN environment and the other one was an environment using a flash caching solution. What all three had in common is that when they were driving a lot of IO the SSD device would be unavailable, for one of them they even had challenges enabling VSAN in the first place before any IO load was placed on it.

With the first customer it took me a while what was going on. I asked him the standard questions:

  • Which disk controller are you using?
  • Which flash device are you using?
  • Which disks are you using?
  • Do you have 10GbE networking?
  • Are they on the HCL?
  • What is the queue depth of the devices?

All the answers were “positive”, meaning that the full environment was supported… the queue depth was 600 so that was fine, enterprise grade MLC devices used and even the HDDs were on the HCL. So what was causing their problems? I asked them to show me the Web Client and the disk devices and the flash devices, then I noticed that the flash devices were connected to a different disk controller. The HDDs (SAS drives) were connected to the disk controllers which was on the HCL, a highly performant and reliable device… The flash device however was connected to the on-board shallow queue depth and non-certified controller. Yes indeed, the infamous AHCI disk controller. When I pointed it out the customers were shocked ,”why on earth would the vendor do that…”, well to be honest if you look at it: SAS drives were connected to the SAS controller and the SATA flash device was connected to the SATA disk controller, from that perspective it makes sense right? And in the end, the OEM doesn’t really know what your plans are with it when you configure your own box right? So before you install anything, open it up and make sure that everything is connected properly in a fully supported way! (PS: or simply go VSAN Ready Node / EVO:RAIL :-))

Slow backup of VM on VSAN Datastore

Someone at out internal field conference asked me a question around why doing a full back up of a virtual machine on a VSAN datastore is slower then when doing the same exercise for that virtual machine on a traditional storage array. Note that the test that was conducted here was done with a single virtual machine. The best way to explain why this is is by taking a look at the architecture of VSAN. First, let me mention that the full backup of the VM on a traditional array was done on a storage system that had many disks backing the datastore on which the virtual machine was located.

Virtual SAN, as hopefully all of you know, creates a shared datastore out of host local resources. This datastore is formed out of disk and flash. Another thing to understand is that Virtual SAN is an object store. Each object typically is stored in a resilient fashion and as such on two hosts, hence 3 hosts is the minimum. Now, by default the component of an object is not striped which means that components are stored in most cases on a single physical spindle, for an object this means that as you can see in the diagram below that the disk (object) has two components and without stripes is stored on 2 physical disks.

Now lets get back to the original question. Why did the backup on VSAN take longer then with a traditional storage system? It is fairly simple to explain looking at the above info. In the case of the traditional storage array you are reading from multiple disks (10+) but with VSAN you are only reading from 2 disks. As you can imagine when reading from disk performance / throughput results will differ depending on the number of resources the total number of disks it is reading from can provide. In this test, as there it is just a single virtual machine being backed up, the VSAN result will be different as it has a lower number of disks (resources) to its disposal and on top of that is the VM is new there is no data cached so the flash layer is not used. Now, depending on your workload you can of course decide to stripe the components, but also… when it comes to backup you can also decided to increase the number of concurrent backups… if you increase the number of concurrent backups then the results will get closer as more disks are being leveraged across all VMs. I hope that helps explaining  why results can be different, but hopefully everyone understands that when you test things like this that parallelism is important or provide the right level of stripe width.

Project Fargo aka VMFork and TPS?

I received some questions this week around how VMFork (aka Instant Clone) will work when TPS is disabled in the future, already answered some questions in comments but figured this would be easier to google. First of all, I would like to point out that in future versions TPS will not be globally disabled, but rather it will disabled for inter-VM page collapsing. Within the VM though pages will be collapsed as normal and the way it works is that each virtual machine configuration will contain a salt and all virtual machines with the same salt will share pages… However, each virtual machine by default will have a unique salt. Now this is where a VMFork’ed virtual machine will differ in the future.

VMFork’ed virtual machines in the future will share the salt, which means that “VMFork groups” can be considered a security domain and pages will be shared between all of these VMs. In other words, the parent and all of its children have the same salt and will share pages (see sched.mem.pshare.salt). If you have a different parent then pages between those VMFork Groups (both parents and its children) will not be shared.

VMware / ecosystem / industry news flash… part 4

VMware / ecosystem / industry news flash time again. Took me a while to get a bunch of them, so some of the news is a bit older then normal.

  • Dell and SuperMicro to offer an EVO:RAIL bundle with Nexenta for file services on top of VSAN!
    Smart move by Nexenta, first 3rd party vendor to add value to the EVO:RAIL package and straight away they partner with both Dell and SuperMicro. I expect we will start seeing more of these types of partnerships. There are various other vendors who have shown interest in layering services on top of EVO:RAIL so it is going to be interesting to see what is next!
  • Tintri just announced a new storage system called the T800. This device can hold up to 3500 VMs in just 4U and provides 100TB of effective capacity. With up to 140K IOPS this device also delivers good performance at a starting price of 74K USD. But more then the hardware, I love the simplicity that Tintri brings. Probably one of the most user/admin friendly systems I have seen so far, and coincidentally they also announced Tintri OS 3.1 this week which brings:
    • Long awaited integration with Site Recovery Manager. Great to see that they pulled this one off, it something which I know people have been waiting for.
    • Encryption for the T800 series
    • Tintri Automation Toolkit which allows for end-to-end automation from the VM directly to storage through both PowerShell and REST APIs!
  • Dell releases the PowerEdge FX. I was briefed a long time ago on these systems and I liked it a lot as it provides a great modular mini datacenter solution. I can see people using these for Virtual SAN deployments as it allows for a lot of flexibility and capacity in just 2U. What I love about these systems is that they have networking included, that sounds like true hyper-converged to me! A great review here by which I recommend reading. Definitely something I’ll be looking in to for my lab, how nice would it be: 4 x FC430 for compute + 2 x FD332 for storage capacity!

That it is for now…