With the announcement last month of VMware Virtual SAN 6.2 and the product finally being GA’ed early this week (kinda hard to not to notice if you paid any attention to the Twitters) there are a few documents every VMware/VSAN administrator needs to have a look at. With new features announced around de-duplication, erasure coding, sparse swap files, etc there are new design elements to pay attention to, new licensing levels, and just a better overall understanding of how the new features function and operate in your environment. Each of the documents below well help address those items along with many more. Happy reading!
During my experience working with VDI/EUC deployments with customers one thing becomes pretty clear during engagements, it’s not necessarily about the actual desktop as much as it is about getting access to the applications that your users need and require to be productive. Over the last few years getting these applications to the end users required a couple of tricks and deployment models to present them. From a VMware View perspective initially you had two “native” options, install the needed application into your golden image or images (which lead to both image and View pool sprawl) or leverage VMware’s ThinApp product to create and isolate the applications from the underlying operating system. With ThinApp came the challenge of the application delivery; a not so robust integration with the Horizon View Administrator console, leveraging Microsoft Group Policy setting to deploy a MSI, and finally logon scripts and file shares.
In August of 2014 VMware added an additional application strategy with its purchase of Cloud Volumes which has since been re-branded to VMware App Volumes. App Volumes leverages an application “layering” approach (similar products are available from UniDesk and LiquidWare Labs), where as the application or applications are installed into a capture virtual machine and saved as a VMDK disk (this is the lite explanation). This VMDK or “layer” can then be mounted and accessed by multiple virtual desktops for a “just in time delivery” mechanism for your application sets.
Seems like the holy grail right? Well for the most part it is, with one exception. Many organizations still have legacy applications that require a specific version of Java, or require an outdated browser such as IE6. This is the beauty of VMware ThinApp, with its ability to virtualize and isolate applications and their dependencies from the operating system you could run multiple versions of Java on the same virtual machine. So, what do you do if you still have legacy applications that are best served being virtualized via ThinApp but you want to use the power of App Volumes to distribute them? Well, you put your ThinApp’s into App Volumes of course!
In a blog post I put out this week I worked through the process for configuring SSD devices in my ESXi hosts to be used for an all flash (AF) VSAN configuration. After getting the AF VSAN up and running in my lab I started moving over a few of my VMware Horizon View 6.2 infrastructure VM’s (Composer, Connection Servers, etc) just to test the waters. After verifying that all was good with the VSAN Datastore, next step was to create a new desktop pool. That is when things went a bit sideways.
After walking through the new pool creation wizard via the View Administrator console I would switch over to my vSphere client to observe the status of the virtual machine cloning operation. After a few seconds I noticed that the clone operation would error out stating “Insufficient disk space on datastore” . The screenshot below display the message:
It seems each year after VMworld I come home excited about some new piece of hardware or software that was announced at the show, or something at a vendor’s booth tht caught my eye. Well as in years passed, this year was no different. After sitting through and seeing a few sessions around an all flash (AF) VMware VSAN configuration I thought I would give it a shot in the home lab.
For the last six or eight months or so I have been running a “hybrid” VSAN configuration in my lab once I was able to get my hands on the bits. While the setup and configuration was easy, the performance (from my configuration) was less then stellar. For the hybrid configuration the flash tier (either SSD or PCIe based devices) are used to provide a read cache/write buffering tier in front of traditional magnetic disks. In my lab the HDD’s are my limiting factor for performance. Using a pair of Western Digital REDs in each host was an economical way (that is cheap) to try out VSAN and get it running, the 5400 RPM drives where just not up to the task for anything “performance” related.
Enter the AF VSAN configuration. After getting home I jumped over to NewEgg.com to look for some good cost per GB SSD drives for the lab. I knew from conversations with Jim Millard ( blog / twitter ) that he has good experience with the 512GB drives from Transcender, and the price was right. I ordered up six drives and drive carriers for my ESXi hosts. After waiting a few days the new toys arrived and I set out on getting my AF VSAN up and running.
Setting up an AF VSAN works pretty much the same way as the hybrid model, except for one catch. We have to flag the flash devices (in my case SSD’s) to not only be identified for use as the read caching/write buffering tier, but also to be used for data disks or for the capacity tier. There are two ways to accomplish this task, the hard way (read that as manual way) or the easy way (read that as automated way).