I’m pleased to share with the community that PernixData has released FVP version 1.5, which has been purring in my lab for a number of weeks and really strutting its stuff. In fact, this is the reason behind my somewhat recent shift to upgrade vCenter to version 5.5 – I wanted to play with FVP using its brand new integration into the VMware Web Client 5.5. In this post, you are going to get an exclusive first look at all of the new and improved features that have been baked into FVP 1.5. Lucky you! 🙂
If you’ve not yet heard of FVP, it’s a server-side flash solution that allows your vSphere VMs to transparently read or write to a distributed pool of local flash devices. It’s also insanely simple to configure and manage due to all of the smarts embedded into the software stack. Want more background? Head on over to my original posts entitled An Early Look at PernixData’s Server-Side Flash Virtualization Platform and PernixData FVP 1.0 Has Arrived At GA.
Say No To Host Reboots
FVP uses a local flash device – be it an SSD or PCIe flash card – to do its magic. Much like with any other hardware change, you’ll most likely need to power down the vSphere host in order to add your flash devices for the initial setup. This would be the case for most any hardware modification in a vSphere host and makes sense to safeguard the host from human error.
Once you have the flash device(s) installed there are no other reboots necessary to install or upgrade FVP. You can do rolling upgrades without reboots, which is pretty awesome since it’s typically a smidge tougher to get an outage window for a reboot than it is for a simple maintenance mode operation. For those looking to use SSH (or ESXi Shell) instead of Update Manager, the install is as simple as:
esxcli software vib install -d --no-sig-check
Once completed, the ESXCLI command will return a “Reboot Required: False” message, further reinforcing the fact that your new VIB file is ready to rock, as shown below:
I’ve installed a variety of consumer grade SSDs from Micron and Kingston and performed updates from FVP 1.X to 1.5 seamlessly in my lab. For most enterprise environments, I’ve focused on the Intel S3700 (or an OEM rebranded version) along with a variety of PCIe cards. Why? These devices are engineered to hold a longer life and more predictable performance patterns, which is further amplified by FVP’s ability to keep a light touch on the flash device and enhance overall usable performance. Consumer grade stuff is fine for a laptop or home lab, but tends to show its cheapness when you apply a non-trivial workload on it.
Web Client 5.5 Integration
I’m guessing that we’re all a little tearful over the departure of the legacy C# vSphere Client, mainly due to its speedy nature, but that is what it is. PernixData recognizes the push from VMware towards the newish vSphere Web Client and has crafted FVP 1.5 to integrate directly with the Web Client. Once the FVP Management server has been installed, a quick restart of the vCenter Web Client service is all it takes to fully integrate FVP into the Web Client. As shown here, PernixData FVP is now part of the Home hierarchy tree in the Wahl Network lab:
If we drill down a bit deeper, you can see that I’ve already created a cluster named … Spongebob. Yes, I have an unhealthy obsession with my porous yellow friend. FVP is spiffy enough to point out that I’m using a self-signed certificate and gives me the ability to easily add an exception for my browser as shown below:
Once I click Add Exception, my browser – in this case, Chrome – asks if I want to allow the use of FVP’s certificate. I have accepted and FVP acknowledges the exception. Slick!
I can now drill into my FVP cluster, named Spongebob, and see all of the usual dashboard data: a summary of resources and consumption, usage and performance monitoring, device and datastore management, and any objects related to my flash cluster.
Let’s review the data you’ll find under each tab in detail.
Monitor Tab
This tab focuses on monitoring the usage and performance statistics of objects within your flash cluster. Usage is all about the consumption of resources – such as how much local and network flash is being consumed by each VM, what policy each VM is set to, and the status of each VM as it relates to write-through or write-back. Below is a look at my virtual machines:
I can also flip over to my flash devices and see similar data from their perspective, including which host the device lives on, how much of my flash device has been consumed, and overall capacity of the flash device:
This gives me several solid clues as to the sizing of my flash devices and can help drive decisions around adding additional devices or increasing the size of my flash devices when a refresh cycle comes up.
Switching to the performance side of monitoring provides a ton of information on each virtual machine or flash device as it relates to IOPS, latency, throughput, flash hit rate, and flash eviction rate. Let’s drill into my Zerto virtual machine, which is quietly replicating my environment to another site:
The graph can be helpful at understanding the local flash performance (orange) versus the datastore performance (purple) that is being hosted on my storage array. The blue line, total effective latency, reflects what the virtual machine is actually experiencing. FVP smooths out latency for this particular VM nicely, but keep in mind that it’s a smallish lab workload and I’m not trying to show off the insane speeds and feeds here.
