What's the advantages/disadvantages of utilizing Netapp's Flash Accel 1.2 software over the about to be released vSphere Flash Read Cache. Are there any documents out there that goes in depth comparing the two products...just curious as they both seem to do the same thing.
I'm the product manager for Flash Accel. Here's my perspective - hope it helps.
At the core, vFRC and Flash Accel are both server read / write-through caches that are intended to increase application / server performance and increase efficiency of backend network storage. Another key similarity they share is that they are both flash hardware agnostic, and can be supported on a variety of server PCI-e flash or SSD drives
Here’s a list of the key differences:
vFRC does not require an agent in the VM, whereas Flash Accel requires an agent in the VM. There are pros and cons of both an agent and an agent-less approach. More details on the comparison further down below.
vFRC is only free to customers with Enterprise Plus level license. Flash Accel is free for all NetApp customers
Only Flash Accel has intelligent data coherency with backend ONTAP with block-level invalidation. Anytime a backend storage system changes data, it has coherency implications on the server cache. Incoherency refers to the server cache containing outdated copy of the data and causes corruption. Not only is Flash Accel aware of changes to data made by ONTAP (via SnapRestore, SDW, VSC etc), it also invalidates only the portion of the cache that contains incoherent data. This means that the cache doesn't have to be wiped out completely and rewarmed again, and a warm cache means a high-performance cache.
Only Flash Accel has a persistent cache. When a VM or server is rebooted, Flash Accel keeps its cache warm and checks / corrects for coherency once the VM or server comes back online. VMs can continue with a warm cache after the reboot. Again, this helps maintain the overall performance of the cache
vFRC gives the user an option to migrate a VM's cache content from one server to another when the VM is vMotioned (via a copy operation), so that VM can run on the destination server with a cache that is already warm. It does make vMotion take a longer, but your VM maintains its performance during migration. Of course, you have the option to disable warm vMotion if you don’t want to live with the longer vMotion time. With the current version of Flash Accel, the migrated VM starts with a cold cache and then needs to be rewarmed. The warm cache vMotion is on our near term roadmap
Flash Accel supports RDM, vFRC does not
Our vision for Flash Accel longer term is to extend ONTAP management capabilities into the host via tight ONTAP / Flash Accel integration. Benefits such as coordinated caching (i.e. dynamically adjust SLO and amount of cache used in Flash Accel vs. Flash Cache vs. Flash Pool), integrated deduplication (i.e. ability to share dedupe information between Flash Accel and ONTAP so that dedupe can be done in ONTAP and communicated to Flash Accel or vice versa, which optimizes the capacity usage and performance across the stack), and others. These features will require ONTAP changes so therefore longer term, but we see current version of Flash Accel as basis and first step towards this vision
Longer term, VMware will provide API to enable server cache partners to plug into vFRC infrastructure
Now let’s talk about the pros and cons of agent-less vs. agent-based approach
First the benefit of agent-less:
Easier to install and manage, especially when the number of VMs under management is large. Flash Accel address this issue by having easy to use bulk agent install feature in our management tool, FAMC.
Without an agent in the VM, a wide array OS versions in the guest VM are easily supported. An agent-based approach requires a different agent for every OS, and that limits the number of OS versions supported
No VM reboot is required on installation, whereas an agent-based approach requires VM reboot.
Now let's look at the benefit of an agent-based approach like Flash Accel:
iSCSI in the VM support. Many NetApp customers choose direct iSCSI connection in the VM for their MSFT SQL environment. iSCSI in the VM support is only possible with an agent-based approach
Application-specific cache optimization. A cache that is customized specifically to the application itself offers the greatest performance / IO benefit. One example of this - best IO performance happens when the block sizes of the cache aligns with the application request and storage file system. So an agent-based approach gives user the ability to change the cache block size to get to that optimal performance
A server cache should ideally have both an agent and well as an agent-less configuration so that customers can choose the option that best fit their environment and requirements. That is the approach Flash Accel will be taking.