Infinio’s Read Caching versus Virtunet’s Read+Write Caching Software
The biggest differences are:
- Virtunet’s VirtuCache accelerates reads and writes. Infinio Accelerator accelerates only reads.
- Infinio doesn’t support Linked Clones or Instant Clones, hence VDI is not supported. We support all VDI features in VMware Horizon and Citrix.
- With us, you can apply caching policy at the datastore and/or VM level versus only at the VM level with Infinio.
- Infinio doesn’t accelerate IO that originates in the VMware OS. VirtuCache accelerates all storage IO originating in ESXi and VMs. The significance of this is in the table below.
|Accelerates both reads and writes.1||Accelerates only reads.
By not caching writes, not only are writes not accelerated but reads that are behind writes on the same thread are not accelerated, and so reads are slowed down as well. 1
|Supports all VDI features in XenDesktop and Horizon, including Linked Clones, Instant Clones, AppVolumes/ AppDisks, vGPU, etc.||Infinio doesn’t support Linked Clones and Instant Clones, so effectively both persistent and non-persistent VDI are not supported.|
|Caching policy can be applied at the VM and/or Datastore level. Since the number of Datastores is typically much less than VMs, its quicker to configure caching for all the VMs in the cluster by assigning caching policy at the Datastore level than at the VM level. All VMs within the Datastore inherit the Datastore wide caching policy by default. You can of course apply a different caching policy at the VM level. When new VMs are created, these VMs automatically inherit the Datastore caching policy. This is especially useful in non-persistent VDI where new VMs are automatically created when users log in.||Caching policy can be applied only at the VM level. So if you have a large number of VMs, the process of configuring caching for all the VMs in the cluster becomes onerous.|
|All storage IO, whether it originates within VMs or VMware Operating System, is accelerated.||Storage IO originating in the VMware OS is not accelerated. So provisioning / deleting VMs, snapshot creation / deletion, backups, shared VMDKs, and VMs with snapshots cannot be accelerated.|
1 – Why caching writes is necessary? The main arguments from read caching vendors for why read caching suffices is that most traditional IT workloads are read dominated and secondly they contend that by caching only reads, the storage appliance is freed up to better service writes. Both these statements are true, but they are not strong enough arguments to not cache writes. In fact not caching writes also slows down reads. Here is the reason. In all applications, reads and writes are interspersed on the same thread. Since Infinio does not cache writes, pending writes in the queue will back up even the read requests behind them that are on the same thread. So even if these reads by themselves could be accelerated by Infinio, because reads and writes are interspersed on the same thread the reads too are slowed down. Secondly, many storage appliances, even the older ones, do well on reads but not on writes, so accelerating even small amount of writes disproportionately improves VM performance. Thirdly, write-intensive applications are also those that are of higher value, as is the case with transaction processing, ERP, healthcare EMR, order processing, and other database driven applications. For instance, entering purchase orders (write intensive job) is possibly higher value than running a report on historical purchase orders (read intensive job). Hence both reads and writes need to be accelerated.