I’ve written in the near past about a number of different products that are helping enterprises use flash as a cache to accelerate their traditional storage workloads. One product that is helping to push the whole market forward, if only by raising awareness of the options in this space, is VMware’s own vSphere Flash Read Cache. Continue reading VMware vSphere Flash Read Cache
In the world of virtualization storage it seems all we talk about lately is flash and SSD. There is a good reason for that. Traditionally, storage capacity and storage performance were directly linked. Sure, you could choose different disk capacities, but in general you needed to add capacity in order to add performance because each disk, each “spindle” could only support a certain number of I/Os per second, or IOPS. This was governed by the mechanical nature of the drives themselves, which had to wait for the seek arm to move to a different place on disk, wait for the seek arm to stop vibrating from the move, wait for the desired sector to rotate underneath the read head, etc. There’s only so much of that type of activity that can be done in a second, and in order to do more of it you needed to add more drives. Of course that has drawbacks, like increased power draw, more parts so more chance of failure, and increased licensing costs since many storage vendors charged based on capacity.
Flash memory takes most of what we know about the physics of storage and throws it away. Because there are no moving parts, the act of seeking on a solid state disk is a completely logical one. There are no heads, no sectors, no rotation speeds. It’s all the speed of light and however fast the controller can go. As such, flash memory can do enormous numbers of IOPS, and if implemented well, it decouples storage performance from storage capacity. You save power, you save data center space, you save money in licensing fees, and your workloads run faster. Continue reading SanDisk FlashSoft for VMware vSphere
As the SSD invasion of the data center continues unabated, we are seeing more host-side caching solutions emerge. These solutions purport to be easier and way less expensive to implement than array-side SSD and flash, and they promise decent performance gains. The Proximal Data AutoCache is one of these products. Continue reading Proximal Data AutoCache 2.0
With SSD, RAM, and flash prices falling but storage vendors maintaining their margins on array hardware there is an increasing niche for flash-based caching solutions. These solutions promise better performance at lower costs than retrofitting your legacy arrays and are becoming quite a market, especially for virtualization infrastructure. Infinio is one startup that is competing in this space. Continue reading Infinio Accelerator
2013 is the year of caching. The VMworld conference was full of news about startups using expensive-yet-fast technologies like flash, SSD, and RAM to make up for deficiencies in storage performance. One of those startups was PernixData, announcing their FVP caching product.
Ask any virtualization administrator what their major pain points are and the first thing on the list will be storage. It isn’t surprising. Storage was likely the first major bottleneck for virtualization, back when it was “the Internet” and not “the cloud.” And as any IT person can tell you, there are two ways storage can be a bottleneck: performance and capacity. Traditionally, the problem of capacity is less complicated to solve than that of performance. To gain capacity you just add disk. To gain performance you needed to select a disk form factor (2.5″ or 3.5″), connection technology (SAS, iSCSI, fibre channel), rotational speed (7200, 10000, 15000 RPM), sometimes a controller (do I get the Dell PERC with 512 MB of cache or 1 GB?), and do the math to figure out how many disks you need to match both the problem of your I/O and its corollary: the problem of your budget. Complicating things, virtualization turned most I/O into random I/O. What might be a nice sequential write from each virtual machine looks pretty random in aggregate. Of course, random I/O is the hardest type of I/O for a disk to do. Continue reading Caching as a Service