I’ve had the pleasure of seeing PernixData a number of times both at our local Toronto VMUGs as well as at VMworld. Also, I have a couple close friends working for Pernix so I’m very familiar with what the solutions they currently offer. One interesting thing about Pernix is that they have a bit of a history of releasing new features and enhancements at Tech Field Day events (See their Storage Field Day 5 presentations) so I’m definitely looking forward to seeing them on June 24th in Boston.
[symple_box color=”yellow” fade_in=”false” float=”center” text_align=”left” width=””]
Disclaimer: As a Virtualization Field Day 5 delegate all of my flight, travel, accommodations, eats, and drinks are paid for. However I do not receive any compensation nor am I required to write anything in regards to the event or the sponsors. This is done at my own discretion.
[/symple_box]
So what do they do?
PernixData in its simplest form is a server side cache play. Their software, FVP, essentially allows you to accelerate both reads and writes utilizing server components, both RAM and SSD drives. Basically they sit in the middle of your data path between your hypervisor sending the I/O and your storage array which receives the I/O. What this does is allow your server components to essentially act as a cache for your storage array – and since they sit right next to all of your compute you can imagine the benefits in terms of efficiency and performance FVP provides.
FVP recognizes that the first thing that comes to mind in looking at all of this is that the cache, the SSD and RAM is not shared storage – so what happens when a host decides to take a walk and brings all of that non-committed write cache with it?. Because of situations just like this Pernix basically replicates any writes across all nodes (or the nodes you chose) in your FVP cluster before acknowledging the write back to the VM – allowing for host failure scenarios and ensuring that your writes are safely written back to your storage array. All this while still supporting advanced vSphere features such as HA and DRS.
So is server-side cache a band-aid?
I’ve heard this term a lot in the industry – stating server side caching is just a band-aid for the real problem – your underlying storage. But when I hear this I ask myself – if Pernix and other companies can deliver me a solution that drives enough IOPs and enough performance to successfully and efficiently run my environment do I really care if my underlying storage isn’t doing that on its own? Honestly if no one is complaining and everything is running up to my expectations I feel like it’s a win-win – not a band-aid.
Pernix definitely has some awesome innovation in their software – FVP covers all angles when it comes to providing that fault tolerant, mirrored, read and write cache for your host. You can enable caching on a per datastore or per VM level – allowing you to accelerate only your most crucial or needed workloads – also, FVP now supports not just block storage, but NFS as well! I have no idea what Pernix has in store for us at VFD5 but you can bet it will be pretty awesome! Once again, you can tune into all the action by watching the live stream on the VFD5 event page – as well, all my content and the live stream will also be on my VFD5 page.
